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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document is part of a series of documents that specify charging functionality and charging management in 
GSM/UMTS networks. The GSM/UMTS core network charging architecture and principles are specified in document 
TS 32.240 [1], which provides an umbrella for other charging management documents that specify: 

- the content of the CDRs per domain and subsystem (offline charging), 

- the content of real-time charging events per domain / subsystem (online charging); 

- the functionality of online and offline charging for those domains and subsystems; 

- the interfaces that are used in the charging framework to transfer the charging information (i.e. CDRs or charging 
events) 

The complete document structure for these TSs is defined in TS 32.240 [1]. 

The present document specifies the Offline and Online Charging description for the IP Multimedia Subsystem (IMS), 
based on the functional descriptions of the IMS in 3GPP TS 23.228 [200]. This charging description includes the offline 
and online charging architecture and scenarios specific to IMS, as well as the mapping of common 3GPP charging 
architecture specified in TS 32.240 [1] onto IMS. It further specifies the structure and content of the CDRs for offline 
charging, and the charging events for online charging. The present document is related to other 3GPP charging TSs as 
follows: 

■ The common 3GPP charging architecture is specified in TS 32.240 [1]; 

■ The parameters, abstract syntax and encoding rules for these CDR types are specified in TS 32.298 [51]. 

■ A transaction based mechanism for the transfer of CDRs within the network is specified in TS 32.295 [54]. 

■ The file based mechanism used to transfer the CDRs from the network to the operator"s billing domain (e.g. 
the billing system or a mediation device) is specified in TS 32.297 [52]. 

■ The 3GPP Diameter application that is used for IMS offline and online charging is specified in TS 32.299 [50]. 

All terms, definitions and abbreviations used in the present document, that are common across 3GPP TSs, are defined in 
the 3GPP Vocabulary, TR 21.905 [100]. Those that are common across charging management in GSM/UMTS domains, 
services or subsystems are provided in the umbrella document TS 32.240 [1] and are copied into clause 3 of the present 
document for ease of reading. Finally, those items that are specific to the present document are defined exclusively in 
the present document. 

Furthermore, requirements that govern the charging work are specified in 3GPP TS 22. 115 [102]. 
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document. 
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3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions given in 3GPP TR 21.905 [50], 3GPP 
TS 32.240 [1], and the following apply: 

billing: function whereby CDRs generated by the charging function are transformed into bills requiring payment. 

Billing Domain: Part of the operator network, which is outside the core network that receives and processes charging 
information from the core network charging functions. It includes functions that can provide billing mediation and 
billing end applications. 

CDR field Categories: the CDR fields are defined in the present document. They are divided into the following 
categories: 

• Mandatory: field that shall be present in the CDR. 

• Conditional: field that shall be present in a CDR if certain conditions are met. 

• Operator Provisionable: Mandatory: A field that operators have provisioned to be included in the CDR for all 
conditions. 

• Operator Provisionable: Conditional: A field that operators have provisioned to be included in the CDR if 
certain conditions are met. 

chargeable event: activity utilizing telecommunications network infrastructure and related services for: 

• user to user communication (e.g. a single call, a data communication session or a short message); or 

• user to network communication (e.g. service profile administration); or 

• inter-network communication (e.g. transferring calls, signalling, or short messages); or 

• mobility (e.g. roaming or inter-system handover); and 

• that the network operator wants to charge for. 

charged party: user involved in a chargeable event that has to pay parts or the whole charges of the chargeable event, 
or a third party paying the charges caused by one or all users involved in the chargeable event, or a network operator. 

charging: function whereby information related to a chargeable event is formatted and transferred in order to make it 
possible to determine usage for which the charged party may be billed. 

Charging Data Record (CDR): record generated by a network element for the purpose of billing a subscriber for the 
provided service. It includes fields identifying the user, the session and the network elements as well as information on 
the network resources and services used to support a subscriber session. In the traditional circuit domain, CDR has been 
used to denote "Call Detail Record", which is subsumed by "Charging Data Record" hereafter. 

charging function: entity inside the core network domain, subsystem or service that is involved in charging for that 
domain, subsystem or service. 

offline charging: charging mechanism where charging information does not affect, in real-time, the service rendered 

online charging: charging mechanism where charging information can affect, in real-time, the service rendered and 
therefore a direct interaction of the charging mechanism with session/service control is required 

partial CDR: CDR that provides information on part of a subscriber session. A long session may be covered by several 
partial CDRs. Two formats are considered for Partial CDRs. One that contains all of the necessary fields; the second has 
a reduced format. 
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3.2 Symbols 



For the purposes of the present document, the following symbols apply: 



Bi 
Ga 
Rf 
Ro 



Reference point for the CDR file transfer from the IMS CGF to the BD. 

Reference point for CDR transfer between a CDF and CGF. 

Offline Charging Reference Point between an IMS Network Entity or an AS and CDF 

Online Charging Reference Point between an AS or MRFC and IMS-GWF and the OCS 



3.3 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

ABNF Augmented Backus-Naur Form 

ACA Accounting Answer 

ACR Accounting Request 

AS Application Server 

AVP Attribute Value Pair 

B2BUA Back-to-Back User Agent 

BGCF Breakout Gateway Control Function 

BS BilHng System 

CCA Credit Control Answer 

CCF Charging Collection Function 

CCR Credit Control Request 

CDF Charging Data Function 

CDR Charging Data Record 

CGF Charging Gateway Function 

CPCF Content Provider Charging Function 

ECF Event Charging Function 

ECUR Event Charging with Unit Reservation 

CSCF Call Session Control Function (I-Interrogating; P-Proxy; and S-Serving) 

lEC Immediate Event Charging 

IMS IP Multimedia Subsystem 

IMS-GWF IMS Gateway Function 

ISC IMS Service Control 

MGCF Media Gateway Control Function 

MRFC Media Resource Function Controller 

MRFP Multimedia Resource Function Processor 

OCS Online Charging System 

SCCF Subscriber Content Charging Function 

SCUR Session Charging with Unit Reservation 

SDP Session Description Protocol 

SIP Session Initiation Protocol 

UA User Agent 

UE User Equipment 

VCC Voice Call Continuity 

VDN VCC Domain transfer Number 
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Architecture Considerations 



4.1 High level IP Multimedia Subsystem (IMS) architecture 

Figure 4.1 depicts the logical IMS architecture, as described in 3GPP TS 23.002 [103] 
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Figure 4.1 : IMS logical architecture 
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4.2 IMS offline charging architecture 

The architecture for IMS offline charging is described in the following figure. The Rf interface is described in clause 
6.1.1 and Bi in clause 6.1.2. 
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Figure 4.2: IMS offline charging architecture 

NOTE: The combination of the CDF/CGF coiTesponds to the 3GPP Rel-5 CCF. 

4.3 IMS online charging architecture 

The architecture for IMS online charging is described in the following figure. The Ro interface is described in clause 
6.2 and ISC in TS 23.228 [201]. 
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Figure 4.3: IMS online charging Architecture 
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5 Charging Principles 

5.1 IIVIS Charging Principles 

The AS and MRFC are able to distinguish whether to apply offline or online charging, i.e. whether to send charging 
information over the Rf interface to the CDF or over the Ro interface to the OCS, which includes ECF and SCF as 
described in chapter 4.3 (or to use both). The decision of which interface to use is based on the information (CDF and/or 
OCS address) the AS/MRFC receives in the SIP signalling and the system configuration as provisioned by the operator. 
If the AS/MRFC only receive the CDF address and do not receive an OCS address then they use only the Rf interface. 
If only the OCS address was provided then they use only the Ro interface. In cases where both CDF and OCS addresses 
are provided it is possible to use both interfaces simultaneously. 

However, operators may overrule the addresses received via the SIP signalling and use their own configured rules 
instead. Operators may configure locally on the AS/MRFC an OCS and/or CDF address. The choice of whether the 
IMS network elements use locally configured addresses or the addresses received by SIP signalling, and the decision on 
which interface(s) to use, is left for operator configuration. 

All other IMS network elements (S-CSCF, P-CSCF, I-CSCF, BGCF and MGCF) apply offline charging via the Rf 
interface using the CDF address as received via SIP signalling or the locally configured CDF address in the IMS 
network element. The S-CSCF supports online charging using: 

the ISC interface, i.e. if the application server addressed over ISC is the IMS Gateway Function, or 

the Ro interface directly instead of the ISC, if the IMS Gateway Function is integrated within the S-CSCF. 

The offline and online charging function addresses transferred in SIP signalling are encoded in the P-Charging- 
Function- Addresses as defined in TS 24.229 [204] and RFC 3455 [406]. The P-Charging-Function- Addresses header 
contains the following parameters: CCF (i.e. CDF) and ECF (i.e. OCS). 

5.1 .2 IMS Charging Correlation 

5.1 .2.1 Basic Principles for IMS Domain Correlation 

The IMS charging correlation information is encoded in the SIP P-Charging-Vector header as defined in the following 
sub clauses. The P-Charging-Vector header contains the following parameters: ICID, access network charging identifier 
and lOI. 

General correlation mechanisms are defined in TS 32.240 [1], and further details about the usage of P-Charging- Vector 
are defined in TS 24.229 [204] and RFC 3455 [406]. 

5.1 .2.2 IMS Charging Identifier (ICID) 

The IMS domain correlation is based on IMS Charging Identifier (ICID) shared between IMS network elements 
involved with the same session/transaction. With ICID it is possible to correlate session/transaction related charging 
data generated in different IMS elements (i.e. x-CSCFs, ASs"). The ICID is included in all SIP methods, if the P- 
Charging-Vector header is present, and transferred through originating and terminating side nodes, except to UE. 

The value of the ICID parameter is identical with the 'icid-value' parameter defined in TS 24.229 [204]. The 'icid-value' 
is a mandatory part of the P-Charging- Vector and coded as a text-based UTF-8 charset (as are all SIP messages). For 
further information regarding the composition and usage of the P-Charging-Vector refer to [204] and RFC 3455 [406]. 

The ICID value is globally unique across all 3GPP IMS networks for a time period of at least one month, implying that 
neither the node that generated this ICID nor any other IMS network element reuse this value before the uniqueness 
period expires. The one month minimum uniqueness period counts from the time of release of the ICID, i.e. the ICID 
value no longer being used. This can be achieved by using node specific information, e.g. high-granularity time 
information and / or topology / location information. The exact method how to achieve the uniqueness requirement is 
an implementation issue. 
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At each SIP session unrelated method, both initial and subsequent (e.g., REGISTER, NOTIFY, MESSAGE etc.), a new, 
session unrelated ICID is generated at the first IMS network element that processes the method. This ICID value is 
contained in the SIP request and response of that SIP transaction and must be valid for the duration of the transaction. 

At each SIP session establishment a new, session specific ICID is generated at the first IMS network element that 
processes the session-initiating SIP INVITE message. This ICID is then used in all subsequent SIP messages for that 
session (e.g., 200 OK, (re-)INVITE, BYE etc.) until the session is terminated. 

5.1 .2.3 Access network charging identifier 

The access network charging identifier is the media flow level data shared among the IMS network elements for one 
side of the session (either the originating or terminating side). This information is used to correlate the access network 
charging data with the IMS charging data. The access network is identified by bearer specific correlation identifier, e.g. 
for Packet Switched Access (GGSN address and PDP context Identifier) or Fixed Broadband Access (Multimedia 
Charging Identifier). The access network charging identifier is populated in the P-Charging-Vector using the access- 
network-charging-info parameter. For further information regarding the composition and usage of the access-network- 
charging-info parameter refer to TS 24.229[204] and RFC 3455 [406]. 

5.1 .2.4 Inter Operator Identifier (101) 

The lOI identifies both originating and terminating networks involved in a session/transaction. The lOI may be 
generated from each side of session/transaction to identify the home networks associated with each side. The orig-ioi 
and term-ioi parameters of P-Charging- Vector represent the originating and terminating operator identifiers. For further 
information regarding the composition and usage of the orig-ioi and term-ioi parameters refer to TS 24.229 [204] and 
RFC 3455 [406]. 

5.1.2.5 Void 

5.2 IMS Offline Charging Principles 
5.2.1 Basic Principles 

The offline charging functionality is based on the IMS network nodes reporting accounting information upon reception 
of various SIP methods or ISUP messages, as most of the accounting relevant information is contained in these 
messages. This reporting is achieved by sending Diameter Accounting Requests (ACR) [Start, Interim, Stop and Event] 
from the IMS network elements to the CDF. 

The Diameter client uses ACR Start, Interim and Stop in procedures related to successful SIP sessions. It uses ACR 
Events for unsuccessful SIP sessions and for session unrelated procedures. Further details are specified in the tables 
below and in clause 5.2.2. 

It is operator configurable in the nodes for which SIP method or ISUP messages an Accounting Request is sent. 
Table 5.2.1.1 describes all possible ACRs that might be sent from a P-CSCF, I-CSCF, S-CSCF, MGCF or BGCF. A list 
of node specific ACRs, along with the AVPs to be included are detailed in TS 32.299 [50]. 

The ACRs to be sent from a MRFC are described in table 5.2.1.2. 

It is configurable for the operators to enable or disable the generation of an ACR message by the IMS node in response 
to a particular "Triggering SIP Method /ISUP Message". However, for those table entries marked with *, the operator 
can enable or disable the ACR message based on whether or not the SIP (Re) Invite message that is replied to by the 
"Triggering SIP Method /ISUP Message" carried piggybacked user data. 
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Table 5.2.1.1 : Accounting Request Messages Triggered by SIP Methods or ISUP Messages 

for all IMS nodes except for MRFC and AS 



Diameter Message 


Triggering SIP Method /ISUP Message 


ACR [Start] 


SIP 200 OK acknowledging an initial SIP INVITE (see note 2) (not applicable for BGCF) 


ISUP:ANM (applicable for the MGCF) 


ACR [Interim] 


SIP 200 OK acknowledging a SIP 

RE-INVITE or SIP UPDATE [e.g. change in media components] (see note 2) 


Expiration of AVP [Acct-lnterim-lnterval] (see note 2) 


ACR [Stop] 


SIP BYE message (both normal and abnormal session termination cases) (see note 2) (not 
applicable for BGCF) 


ISUP:REL (applicable for the MGCF) 


ACR [Event] 


SIP 200 OK acknowledging non-session related SIP messages, which are: 


SIP NOTIFY (see note 1 and note 2) 


SIP MESSAGE 


SIP REGISTER (see note 1) 


SIP SUBSCRIBE (see note 3) 


SIP PUBLISH 


SIP 200 OK acknowledging an initial SIP INVITE (only for BGCF) 


SIP 202 Accepted acknowledging a SIP REFER or any other method 


SIP Final Response 2xx (except SIP 200 OK) 


SIP Final/Redirection Response 3xx 


SIP Final Response (4xx, 5xx or 6xx), indicating an unsuccessful SIP session set-up 


SIP Final Response (4xx, 5xx or 6xx), indicating an unsuccessful session-unrelated procedure 


SIP CANCEL, indicating abortion of a SIP session set-up (see note 2) 


l-CSCF completing a Cx Query that was issued in response to a SIP INVITE 


NOTE 1 : SIP REGISTER with its "Expires" header field or "Expires" parameter equal to or local deregistration due to 

expiry means Deregistration (see 3GPP TS 24.229 [204]). 
NOTE 2: (only for l-CSCF): This trigger may only occur if l-CSCF is acting in THIG mode. 
NOTE 3: SIP SUBSCRIBE with the field "Expires" set to means unsubscribe. 



Table 5.2.1.2: Accounting Request Messages Triggered by SIP Methods for the MRFC 



Diameter 
Message 


Triggering SIP Method 


ACR [Start] 


SIP 200 OK acknowledging an SIP INVITE for initiating a multimedia ad hoc conferencing session 


ACR [Interim] 


SIP ACK acknowledging a SIP INVITE to connect an UE to the conferencing session 


SIP REINVITE (see Note 1) 


SIP BYE (see Note 2) 


Expiration of AVP [Acct-lnterim-lnterval] 


ACR [Stop] 


SIP BYE message (see Note 3) 


SIP CANCEL (see Note 3) 


SIP Final Response with error codes 4xx, 5xx or 6xx indicating termination of an ongoing session 
(see Note 3) 


ACR [Event] 


SIP Final/Redirection Response 3xx 


SIP Final Response with error codes 4xx, 5xx or 6xx indicating termination of an ongoing session 


SIP CANCEL, indicating abortion of a SIP session set-up 


SIP REFER 


SIP SUBSCRIBE 


NOTE 1 : This trigger only applies to a user joining an ongoing conferencing session 
NOTE 2: This trigger only applies to a user leaving an ongoing conferencing session 
NOTE 3: This trigger only applies if this causes the ongoing conferencing session to terminate 
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5.2.2 Diameter Message Flows and Types 

The flows described in the present document specify the charging communications between IMS entities and the 
charging functions for different charging scenarios. The SIP messages and Diameter transactions associated with these 
charging scenarios are shown primarily for general information and to illustrate the charging triggers. They are not 
intended to be exhaustive of all the SIP message flows discussed in TS 24.228 [200] and they depend on the Diameter 
Accounting Requests triggers configured by the operator. 



5.2.2.1 



Message Flows - Successful Cases and Scenarios 



5.2.2.1.1 



Session Establishment - Mobile Origination 



The following figure shows the Diameter transactions that are required between CSCF and CDF during session 
establishment originated by a UE. 



Visited Network 



Home Network 



UE 



1. INVITE 




2. 200 OK 




P-CSCF 



CDF 

(visited) 



1. INVITE 



S-CSCF 



CDF 

(home) 



Service Control 



1. INVITE 



More SIP signalling 



2. 200 OK (Invite) 



5. Accounting Requ ;st [Start] 



2. 200 OK (Invite) 



Service Control 



Open a P-CSCF CDR 



6. Accounting Answe|r 

K 



3. Accounting Request [Start] 




Open a S-CSCF CDR 



4. Accounting Answe 

K 



More SIP signalling 




SIP Session established 



"1 1 1 1 1 

Figure : Message Sequence Chart for Session Establishiment (IVIobile Origination) 



1. 

2. 
3. 



4. 
5. 
6. 



The session is initiated. 

The destination party answers and a final response are received. 

Upon reception of the final response, the S-CSCF sends an Accounting-Request with 

Accounting-Record-Type indicating START_RECORD to record start of a user session and start of 

a media component in the S-CSCF CDR. 

The CDF acknowledges the reception of the data and opens an S-CSCF CDR. 

Same as 3, but for P-CSCF. 

Same as 4, but creating a P-CSCF CDR. 
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5.2.2.1.2 



Session Establishment - Mobile Termination 



The following figure shows the Diameter transactions that are required between CSCF and CDF during a session 
establishment that is terminated to a mobile. The I-CSCF is only involved in the INVITE transaction. 



visited Network 



Home Network 



UE 



P-CSCF 




CDF 

(visited) 



S-CSCF 



CDF 

(liome) 



I-CSCF 



Cx Query with the HSS 



2. Accounting Request 



Create I-CSCF CDR 



Service Control 



3. Accounting Answer ^ 



More SIP signalling 




iting Reque^ 



[Start] 



Open P-CSCF CDR 



6. Accounting Answei 



7. Accounting Requ^? t [Start] 



Open S-CSCF CDR 



8. Accounting Answe 
< 



More SIP signalling 



[Event] 





SIP Session established 



Figure : Message Sequence Chart for Session Establishiment (lUlobile Termination) 



1. 

2. 

3. 
4. 

5. ■ 



The session is initiated. 

Upon completing a Cx query the I-CSCF sends an Accounting Request with the 

Accounting-Record-Type set to EVENT. 

The CDF acknowledges the data received and creates an I-CSCF CDR. 

The destination party answers and a final response are sent. 

These steps are identical to the corresponding steps described in clause 5.2.2.1.1. 
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5.2.2.1.3 



Mid-Session Procedures 



The following figure shows the Diameter transactions that are required between CSCF and CDF when a UE generates a 
SIP (Re-)INVITE or SIP UPDATE in mid-session, e.g. in order to modify media component(s), or when the hold and 
resume procedure is executed. 



Visited Networlt 



Home Network 



UE 



CDF 

(visited) 



I 



CDF 

(iiome) 



SIP Session ongoing 



1. INVITE/ 
UPDATE 




1. INVITE/ 
UPDATE 



Service Control 



I. INVITE/ 
UPDATE 



More SIP signalling 



2. 200 OK (Invite/Update) 



2. 200 OK (Invite/Update) 



5. Accounting Request [Interiin 



2. 200 OK (Invite/U] idate) 



Service Control 



Update the P-CSCF CDR 



6. Accounting Answer 

k — 



3. Accounting Request [Interim] 



Reqi^ 




Update the S-CSCF CDR 



4. Accounting Answer 



SIP Session continues 



Figure : Message Sequence Chart for Media Modification 



1. 

2. 
3. 



4. 
5. 
6. 



Modified media information is received from the subscriber. 

The destination party acknowledges the media modification. 

At modification of a media, the S-CSCF sends Accounting-Request with Accounting-Record-Type 

indicating INTERIM_RECORD to record modification of a media component in the S-CSCF 

CDR. 

The CDF acknowledges the reception of the data and updates the S-CSCF CDR. 

Same as 3, but for P-CSCF. 

Same as 4, updating the P-CSCF CDR. 
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5.2.2.1.4 



Session Release - Mobile Initiated 



The following figure shows the Diameter transactions that are required between CSCF and CDF for a session release 
that is initiated by the UE. 



UE 



l.BYE 



Visited Network 



6. 200 OK 



P-CSCF 



CDF 

(visited) 



2. Accounting Reque it [Stop] 



Close the P-CSCF CDR 



J>. Accounting l 



,6. 200 OK 



Home Network 



S-CSCF 



CDF 

(home) 



Service Control 



4. Accounting Reque it [Stop] 



Close die S-CSCF CDR 



J>. Accounting 



AnsW' :r 



6. 200 OK 



Figure : Message Sequence Chart for Session Release 



1. 

2. 



3. 
4. 
5. 
6. 



The session is released. 

At session termination the P-CSCF sends Accounting-Request with Accounting-Record-Type 

indicating STOP_RECORD to record stop of a session and stop of a media component in the 

P-CSCF CDR. 

The CDF acknowledges the reception of the data and closes the P-CSCF CDR. 

Same as 2, but for S-CSCF. 

Same as 3, closing the S-CSCF CDR. 

The release is acknowledged. 
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5.2.2.1.5 



Session-Unrelated Procedures 



The following figure shows the Diameter transactions that are required between CSCF and CDF for session-unrelated 
IMS procedures, i.e. those that relate to the Diameter ACR [Event], as listed in Table 5.2.1.1. 



visited Network 



Home Network 



UE 




P-CSCF 



1. SIP Request (e.g. 

> 



2. SIP Response 



CDF 

(visited) 



SUBSCRIBE) 
1 . SIP Request (e.g. 



S-CSCF 



SUBSCRIBE) 



CDF 

(iiome) 



Service Control 



More SIP signalling 



2. SIP Response 



5. Accounting Requi st [Event] 



Req\jt 



Create P-CSCF CDR 



6. Accounting Answer 



3. Accounting Request [Event] 




Create S-CSCF CDR 



4. Accounting AnsW' '.r 



Figure : Message Sequence Chart for Session-Unrelated Procedure 



1. 

2. 



The P-CSCF receives a "SIP Request" (e.g. SUBSCRIBE) from the subscriber. 
The "SIP Request" is acknowledged by the "SIP Response" as follows: 

in the successful case, a 200 OK message is returned; 

in case of failure an appropriate SIP error message is returned. 



Depending on the used SIP method, there might be additional signalling between steps 1 and 2. 



3. 



4. 
5. 
6. 



After the completion of the procedure, the S-CSCF sends Accounting-Request with Accounting- 
Record-Type indicating EVENT_RECORD to record transaction specific information in the 
S-CSCF CDR. 

The CDF acknowledges the reception of the data and produces an S-CSCF CDR. 
Same as 3, but for P-CSCF. 
Same as 4, creating a P-CSCF CDR. 
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5.2.2.1.6 



Session Establishment - PSTN Initiated 



The following figure shows the Diameter transactions that are required between MGCF and CDF during session 
establishment initiated from the PSTN side. 



PSTN 



l.IAM 



4. ANM 



Home Network 



MGCF 



CDF 

(home) 



2. INVITE 



More SIP/ISUP signalling 



3. 200 OK (Invite) 



5. Accounting Request [Start] 



Open a MGCF CDR 



6. Accounting Answer 



More SIP signalling 



Session established 



Figure : Message Sequence Chart for Session Establishment (PSTN Initiated) 

1 . The session is originated from the PSTN. 

2. The session setup is triggered in the IMS. 

3. The destination party answers and a final response are received. 

4. MGCF forwards an answer message to the PSTN. 

5. Upon reception of the final response, the MGCF sends an Accounting-Request with 

Accounting-Record-Type indicating START_RECORD to record start of a user session and start of a media component 
in the MGCF CDR. 

6. The CDF acknowledges the reception of the data and opens a MGCF CDR. 
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5.2.2.1.7 



Session Establishment - IMS Initiated 



The following figure shows the Diameter transactions that are required between BGCF, MGCF and CDF during session 
establishment initiated from the IMS side. 



Home Network 




Figure : Message Sequence Chart for Session Establishment (IMS Initiated) 



1. 

2. 
3. 
4. 
5. 



6. 

7. 



The session is originated from the IMS. 

A session towards PSTN is established. 

The destination party answers and an answer message are received. 

A final response message is sent to the session originator. 

Upon reception of the answer message, the MGCF sends an Accounting-Request with 

Accounting-Record-Type indicating START_RECORD to record start of a user session and start of 

a media component in the MGCF CDR. 

The CDF acknowledges the reception of the data and opens a MGCF CDR. 

Upon reception of the 200 OK message, the BGCF sends an Accounting-Request with 

Accounting-Record-Type indicating EVENT_RECORD to record start of a user session and start 

of a media component in the BGCF CDR. 

The CDF acknowledges the reception of the data and creates a BGCF CDR. 
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5.2.2.1.8 



Session Release - PSTN Initiated 



The following figure shows the Diameter transactions that are required between MGCF and CDF during a PSTN 
initiated session release. 



Home Network 



MGCF 



CDF 



PSTN 



Session ongoing 



2. BYE 



l.REL 



IRLC 



4. Accounting Request [! top] 



Qose the MGCF CDR 



5. Accounting Ans\\er 



Figure : Message Sequence Chart for Session Release (PSTN initiated) 



1. 

2. 
3. 
4. 



5. 



The session release is initiated from PSTN. 

Session release continues within IMS. 

The reception of the release message is acknowledged. 

Upon reception of the release message, the MGCF sends an Accounting-Request with 

Accounting-Record-Type indicating STOP_RECORD to record stop of a session in the MGCF 

CDR. 

The CDF acknowledges the reception of the data and closes the MGCF CDR. 
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5.2.2.1.9 



Session Release - IMS Initiated 



The following figure shows the Diameter transactions that are required between MGCF and CDF during a IMS initiated 
session release. 

Home Network 



MGCF 



CDF 



PSTN 



Session ongoing 



l.BYE 



2. REL 



3. RLC 



4. Accounting Request [Stop] 



Close the MGCF CDR 



5. Accounting Answer 



Figure : Message Sequence Chart for Session Release (IMS initiated) 



1. 

2. 
3. 
4. 

5. 



The session release is initiated from the IMS side. 

A release message is sent towards PSTN. 

The acknowledgement of the release message is received from PSTN. 

Upon reception of the BYE message the MGCF sends an Accounting Request with Accounting 

Record Type indicating STOP_RECORD to record stop of a session in the MGCF CDR. 

The CDF acknowledges the reception of the data and closes the MGCF CDR. 
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5.2.2.1.10 



Multi-Party Call 



The following figure shows the establishment of an ad hoc conference (multiparty call). An AS (acting as B2BUA) 
performs third party call control with the MRFC, where the S-CSCF is in the signalling path. The Application Server 
that is in control of the ad hoc conference is aware of the MRFC capabilities. Note that only accounting information 
sent from the MRFC is shown in detail in the figure. The SIP messages are for illustrative purpose only. 



UE-1 



AS 



~1 
1. INVITE (MPTY) 



S-CSCF 



CDF 



1 . INVITE (MPTY ) 



Service Logic 



MRFC 



2. INVITE (UE-2 SDP) 2. INVITE (UE-2 SDP) 



3. ^0OK(UE-2SD^) 3. 200 OK (UE-2 SDP) 



UE-2 



4. A ccounting request [Start] 



Open MRFC CDR 



6. INVITE (UE-2 S^P) 

7. ^0OK(UE-2SD ^ ) 



5. A ccounting Answer 

6. INVITE (UE-2 SDP) 



7. 200 OK (UE-2 SDP) 



8. ACK(UE-2SDP ^^ 8. ACK (UE-2 SDP) 



9. Accounting request [Interim] 
1^ 



Update MRFC CDR 



11 . ACK (UE-2 SD^) 



10. Accounting Answe r 
11. ACK (UE-2 SDP) 



12 . INVITE (UE-3 ^DP) 12. INVITE (UE-3 SDP) 



13 .200OK(UE-3SDP ) 13. 200 OK (UE-3 SDP) 



14. INVITE (UE-3 SDP) 



15 . 200 OK (UE-3 Sl^ 



14. INVITE (UE-3 SDP) 



15. 200 OK (UE-3 SDP) 



16 . ACK (UE-3 SD j ^) 16. ACK (UE-3 SDP) 



17. Accounting request [Interim] 



Update MRFC CDR 



1 8. Ac counting Answe r 



19 . ACK (UE-3 SD | ^) 



19. ACK (UE-3 SDP) 



20 . INVITE (UE-1 SDP) 



20. INVITE (UE-1 SDP) 



21 .200 OK (UE-1 SljP) 21 . 200 OK (UE-1 SDP) 



22. 200 OK 



(MPT'^ 



23. 200 OK (MPTY) 



24 . ACK (UE-1 SD j ^) 24. ACK (UE-1 SDP) 




25. Accounting request [Interim] 



Update MRFC CDR 



26. Ac counting Answe r 



UE-3 



Figure : Message Sequence Chart for Multi-Party Call Establishment in MRFC 
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I. Sessions exist between UE-1 and UE-2, and between UE-1 and UE-3. A request is received from 
UE-lfor putting all parties together to a multi-party call. 

2.-3. Request and acknowledgement to initiate multi -party call. MRFC assigns a conference-ID that is 

used by the AS in subsequent interactions with the MRFC in INVITE messages connecting other 
endpoints (see TS 23.228 [201]). Path establishment between AS and MRFC for UE-2. 

4. At start of session establishment the MRFC sends an Accounting-Request with Accounting- 
Record-Type indicating START_RECORD to record start of multi-party call in the MRFC CDR 

5. The CDF acknowledges the reception of the data and creates the MRFC CDR. 'Calling Party 
Address', 'Service Request Time Stamp', 'Service ID' (holding the conference-ID) etc. are included 
in the MRFC CDR 

6-7. Path establishment between UE-2 and AS. Same ICID is used as for the path between AS and 

MRFC for UE-2 (step 2. - 3.). 
8 Acknowledgement of path between AS and MRFC for UE-2. 

9. The MRFC may send an Accounting-Request with Accounting-Record-Type indicating 
INTERIM_RECORD to report that UE-2 has been connected to the multi-party call. 

10. The CDF acknowledges the reception of the data and includes UE-2 in the field 'Application 
Provided Called Parties' of the MRFC CDR. 

II. Acknowledgement of path between AS and UE-2. Now a path between UE-2 and MRFP via AS is 
established. 

Request and acknowledgement to establish path between AS and MRFC for UE-3. 
Path establishment between UE-3 and AS. Same ICID is used as for the path between AS and 
MRFC for UE-3 (step 12. - 13.). 

Acknowledgement of path between AS and MRFC for UE-3. 

The MRFC may send an Accounting-Request with Accounting-Record-Type indicating 
INTERIM_RECORD to report that UE-3 has been connected to the multi-party call. 

18. The CDF acknowledges the reception of the data and includes UE-3 in a new field 'Application 
Provided Called Parties' of the MRFC CDR. 

19. Acknowledgement of path between AS and UE-3. 
20-21. Request and acknowledgement to establish path between AS and MRFC for UE-1. Same ICID is 

used as for the path between UE-1 and AS (step 1.). 
22 - 23. Request for multi-party conference with UE-2 and UE-3 is acknowledged to UE 1. Implicit 

acknowledgement of path UE-1 to AS. 

24. Acknowledgement of path between AS and MRFC for UE-1. 

25. The MRFC may send an Accounting-Request with Accounting-Record-Type indicating 
INTERIM_RECORD to report that UE-1 has been connected to the multi -party call. 

26. The CDF acknowledges the reception of the data and includes the field 'Service Delivery Start 
Time Stamp' into the MRFC CDR. 

27 -28. UE-1 acknowledges the multi -party call session establishment. 

NOTE: It is in the responsibility of the AS to terminate the sessions existing at the beginning of the multi-party 
call establishment between UE-1 and UE-2 and between UE-1 and UE-3 (see step 1.) in case of 
successful multi-party call establishment. This is not shown in the diagram above. 



12- 


-13. 


14. 


-15, 


16. 




17. 
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5.2.2.1.11 



AS Related Procedures - AS Acting as a Redirect Server 



Application servers may support a multitude of services which are not specified in 3GPP standards. Therefore it is not 
possible to standardise charging flows and procedures for those services. However, for all such services, the AS may 
apply either Event Charging, where ACR [Event] messages are generated, or Session Charging, using ACR [Start, Stop 
and Interim]. The following clauses depict one example for each of the two scenarios. The first procedure, AS acting as 
a Redirect Server, depicts the "event" case, while the second procedure, AS acting as a Voice Mail Server, depicts the 
"session" case. 

The following figure shows the case where an Application Server acts as a Redirect Server. In the figure below, UE-1 
sets up a session towards UE-2 but due to Call Forwarding functionality located in the AS, a new number (to UE-3) is 
returned to UE-1. Finally UE-1 sets up the session towards UE-3. 



Originating UE-l 
home network 



Terminating UE-2 Home Network 



Terminating UE-3 
liome network 



S-CSCF 



1. INVITE 



AS 



Service control 



6. 302 MOVED TEMPORARILY 



7. ACK 



. INVITE 



1. INVITE 



CDF 

(home) 



Application performs 
number translation 



2. 302 MOVED TEMPORARILY 



3. ACK 



4. Accounting Request [Eve 



It] 



Create an AS CDR 



J>. Accounting Answer 



Setting up session towards UE-3 



Figure : Message Sequence Chart for AS Acting as a Redirect Server 



1. 

2. ■ 
4. 



3. 



5. 
6-7. 



Sessions initiated by UE-1 towards UE-2. 

Response indicating that session should be redirected towards another number (UE-3). 

After successful service execution, the AS sends Accounting-Request with 

Accounting-Record-Type indicating EVENT_RECORD to record service specific information in 

the AS CDR. 

The CDF acknowledges the reception of the data and creates the AS CDR. 

Response indicating that session should be redirected towards another number (UE-3). 

Session is initiated by UE-1 towards UE-3. 
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5.2.2.1.12 



AS Related Procedures - AS Acting as a Voice Mail Server 



The following figure shows the case where an Application Server acts as a Voice Mail Server. S-CSCF invokes the AS 
acting as Voice Mail Server according to procedure as defined in TS 23.218 [203]. 



S-CSCF 



AS (Voice 
Mail) 



CDF 



SIP signalling 



1. Invite 



Voice mail service invoked. 



2. 200 OK (Invite) 



3. Accounting Request [Start] 



Open an AS CDR 



4. Accounting Answer 



Voice mail session (playing announcements, etc.). . . When voice mail ends, tearing down session 



5. BYE 



6. Accounting Request [Step] 



Close the AS CDR 



7. Accounting Answer 



Figure : Message Sequence Chart for AS Acting as a IVIail Server 



1. 

2. 

3. 

4. 

5. 
6. 

7. 



AS receives the INVITE from the S-CSCF. 

AS acknowledges the initiated Voice Mail session by issuing a 200 OK in response to the 
INVITE. 

AS sends Accounting-Request with Accounting-Record-Type indicating START_RECORD to 
record start of a voice mail session. 

The CDF acknowledges the reception of the Accounting-Request with Accounting-Record-Type 
indicating START_RECORD and opens a AS CDR. 
Voice mail session release is initiated. 

Upon reception of release message AS sends an Accounting-Request with Accounting-Record- 
Type indicating STOP_RECORD to record stop of a session in the AS CDR. 
The CDF acknowledges the reception of the data and closes the AS CDR. 
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5.2.2.1.13 



AS Related Procedures - AS Acting as a VCC AS 



5.2.2.1.13.1 



VCC UE originating call from IMS and Domain Transfer IMS to CS 



The following figure shows the case where an Application Server acts as a Voice Call Continuity AS (VCC AS). It 
illustrates the Diameter transactions that are required for VCC UE originating call from IMS (A.) followed by a Domain 
Transfer from IMS to CS (B.) 

A. VCC UE Originating call from IMS and routed to IMS 



Originating UE-1 (VCC User) Home networl< 



Terminating UE-2 home 

network 



VMSC/ 
VLR 



-1. SIP INVITE {B 



-28. SIP2C0OKto1 



-Party, Call ID#1)- 



VGCAS 
gsmSCF 
/CCCF 



2. Call Control & 
Service Triggering 



3. SIP INVITE (B 
"party, Call ID#1)" 



4. Anchoring 
Decision 



5. SIP INVITE (B 
■party. Call ID#2)" 



S-CSCF 



-6. SIP INVITE (B Party, Call ID#2)- 



-13. SIP200OK- 



-14. ACR (Start)- 



7. Call Control & 
Service Triggering 



lb. Open S-CSCh 

CDRforthe Remote 

leg (Call ID#2) 



17. SIP 200 OK 
to 5. ■" 



21. SIP200OK_ 
' to 3. 



-18. ACR (Start). 



19. Open VCC AS 

CDR for the Remote 

leg (Call ID#2) 



22. AC R (Starts 



23. Open VCC AS 

CDRforthe 

Access leg (Call 

lcl#1) 



-25. ACR (Start)- 



26. Open S-CSCF 

CDR for the 

Access leg(Call 

ld#1) 



-8. SIP INVITE (B Party, Call ID#2)». 

I 
• 9. SIP 200 OK 



-10 ACR(Start)^ 



11. Open S-CSCF 
CDR 



Figure: Message Sequence Chart VCC UE originating call from IMS and Domain Transfer IMS to CS 

1. The VCC session is initiated 
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2. The S-CSCF validates the service profile, and invokes any appropriate service logic required for this 
user. 

3. The S-CSCF forwards the INVITE request message to the VCC AS, according to the service 
origination logic defined by initial Filter Criteria (iFC) in the subscriber profile of the HSS. 

4. The VCC call is anchored at the VCC AS in the home IMS Domain upon reception of the SIP Invite 
(Call Id#l) 

5 and 6. The S-CSCF forwards the INVITE request message to the terminating network (Call Id#2) 

7. The S-CSCF in the terminating network performs call control and service triggering for the incoming 

call 

The session is conveyed to the UE-2 in the terminating network 

The destination party answers and a final response 200 OK is received. 

10. Upon reception of the final response, the S-CSCF in the terminating network sends an Accounting- 
Request with 

Accounting-Record-Type indicating START_RECORD to record start of a user session and start of a 
media component in the S-CSCF CDR. 

1 1 . and 12 The CDF from the terminating network opens an S-CSCF CDR and acknowledges the reception of the 

data 

13. The final response 200 OK is transmitted to the S-CSCF in the Originating network 

14. Upon reception of the final response, the S-CSCF in the originating network sends an Accounting- 
Request with Accounting-Record-Type indicating START_RECORD to record VCC call routing and 
start of a user session/media component in the S-CSCF CDR. 

15. and 16 The CDF from the Originating network opens an S-CSCF CDR related to the Remote leg and 

acknowledges the reception of the data. 

17. Same as 13. but for VCC AS (Remote leg) 

18. Same as 14. but for the VCC AS (Remote leg) 

19. and 20. Same as 15. and 16. but opening a VCC AS CDR related to the Remote leg 

21. Same as 13. but for VCC AS (Access leg) 

22. Same as 14. but for the VCC AS (Access leg) 

23. and 24. Same as 15. and 16. but opening a VCC AS (Access leg) 

25. Same as 14. but for the S-CSCF (Access leg) 

26. and 27. Same as 15. and 16. but opening a VCC AS (Access leg) 

28. The final response to SIP Invite (Call Id#l) is received by the UE-1 
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B. Domain Transfer from IMS to CS 



Originating UE-1 (VCC User) Home network 



Terminating UE-2 iiome 
networl< 



VMSC/ 
VLR 



29.SETUP 
(VCC VDNr 



30.Retreive 

-VCC User profile' 

at CS Connection 



HLR/ 
HSS 



34. Open MSC 
MOC Record 



-40. Alerting- 
-42. Connect- 



MGCF 



S-CSCF 



-31. CAP Initial DP- 



-33. CAP Continue- 



-35. lAM (VDN)- 



36. Translate VDN 
in VCCASPSI 



-39. ACM- 

I 
-41. ANM- 



56. SIP BYE_ 

(CALLID#1) 



VCC AS 

gsmSCF 

/CCCF 



CDF 



32. Detects VCC 

User is in IMS Call 

with calling number 

= MSISDN 



_37. SIP INVITE (VDN-VCC AS_ 
PSI) 

38. SIP 200 OK 



-43. ACR Start- 



-44. AC A - 



56. SIP BYE_ 
'"(CALLID#1) 



-38A. ACRStart> 



S-CSCF 



38B. Open VCC AS 

CDR for the new 

Access leg (Call 

ID#T) 



-38C. ACA- 



44. Open MGCP 
CDR 



-46. SIP UPDATE (Gall ID#2))- 



-49. SIP 200 OK- 



-50. ACR Interim* 



51. Update VCC AS 

CDR for the Remote 

leg (Call ID#2) 



I — 52. AC A 

-57. ACR stop* 



58. Close VCC AS 

CDR for the Access 

leg (Call ID#1) 



-59. ACA- 



-60. ACR Stop- 



61. Close S-CSCF 

CDR for the Access 

leg (Call ID#1) 



-62. AC A - 



CDF 



-47. SIP UPDATE (Call ID#2)>- 

I 
4 48. SIP 200 OK 



-53. ACR lnterim« 



54. Update S-CSCF 
CDR 



-55. ACA- 



Flgure: Message Sequence Chart VCC UE originating call from IMS and Domain Transfer IMS to CS 

(Continued) 
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29. The VCC User (UE-1) originates a voice call in the CS domain using the VCC Domain Transfer Number 

(VDN) of the VCC function to establish an Access Leg via the CS domain and request Domain 
Transfer of the active IMS session to CS Domain. 

30. The originating call is processed in the CS network according to CS origination procedures. The user profil is 

retrieved from the HLR with the CAMEL Detection points for VCC. 

3 L A CAP Initial DP message is sent to the VCC AS to get instructions on how to process the call 

32. The VCC application detects that the user is in IMS call 

33. It responds with a CAP continue 

34. The MSC opens a MOC Record as defined in 3GPP TS 32.250 [2] 

35. The VMSC routes the call towards the user"s home IMS network via an MGCF in the home network 

36. The VCC AS PSI DN is resolved using the VDN at the CS network 

37. The MGCF initiates an INVITE towards the VCC AS in the home IMS of the originating VCC user. This 

message is routed based on one of the standard procedures specified for PSI based Application Server 
Termination. 

38. 39, 40, 41 and 42. The VCC AS completes the estabhshment of the Access Leg using normal CS to IMS 

procedures. 

38A. Upon generation of the final response, the VCC AS in the home IMS of the originating VCC user 

sends an Accounting-Request with Accounting-Record-Type indicating START_RECORD to record 
start of a user session in the VCC AS-CDR. 

38B and 38C. The CDF from the originating network opens an AS CDR and acknowledges the reception of the data. 

43. Upon reception of the final response, the MGCF sends an Accounting-Request with Accounting- 

Record-Type indicating START_RECORD to record start of a user session in the MGCF CDR. 

44 and 45. The CDF from the originating network opens an MGCF CDR and acknowledges the reception of the 

data 

46. and 47. The VCC AS performs the Domain Transfer by updating the Remote Leg with the connection 

information of the newly established Access Leg using the Access Leg Update procedure toward 
remote end. It sends an UPDATE message. The new SDP in the UPDATE message indicates that the 
IP address towards the VCC UE is changed: the IP address that was previously the IP address of the 
VCC UE is changed into the IP address of the MGW.The new bearer path goes now from the VCC 
UE to the MSC, the IM-MGW and then to the other end-point network. 

48 and 49. The 200 OK responses to the SIP Update are received. 

50. At Access Leg update the VCC AS sends Accounting-Request with Accounting-Record-Type 
indicating INTERIM_RECORD to record update of a session in the VCC AS CDR. 

51. and 52. The CDF closes the AS CDR in the originating network and acknowledges the reception of the data 
53. Same as 50, but for S-CSCF in the terminating network. 

54 and 55. Same as 51 and 52 updating the S-CSCF CDR in the terminating network. 

56. The source Access Leg which is the Access leg previously established over IMS is subsequently 
released 

57. At session termination the VCC AS sends Accounting-Request with Accounting-Record-Type 
indicating STOP_RECORD to record stop of a session and stop of a media component in the VCC AS 
CDR. This CDR may be generated with special handling. One example of special handling is to zero 
rate the IMS resource usage for the Access leg establishment. This can be performed using the 
"Service Specific Data" parameter in the VCC AS CDR indicating the anchoring of a VCC call. 

58. and 59. The CDF closes the AS CDR for initial Access leg and acknowledges the reception of the data 
60. Same as 57, but for S-CSCF. 

61 and 62. Same as 58 and 59 closing the S-CSCF CDR related to the initial Access leg. This CDR may be 

generated with special handling. One example of special handling is to zero rate the IMS resource 
usage for Access leg establishment. This can be performed using the correlation mechanism with the 
VCC AS CDR for Access leg. 



5.2.2.1 .13.2 VCC UE originating call from CS and Domain Transfer CS to IMS 

The following figure shows the case where an Application Server acts as a Voice Call Continuity AS (VCC AS). It 
illustrates the Diameter transactions that are required for VCC UE originating call from CS (C.) followed by a Domain 
Transfer from CS to IMS (D.) 
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C. VCC UE Originating call from CS and routed to IMS 

Originating UE-1 (VCC User) Home network 



Terminating UE-2 liome 
network 



VMSC/ 
VLR 



1. SETUP 
(B-Party DN) 



HLR/ 
HSS 



2. Retreive 
■VCC User profile ► 
at CS Connection 



6. Open MSC 
MOC Record 



<30. Alerting- 



«32. Connect- 



MGCF 



S-CSCF 



-3. CAP Initial DP- 



-5. CAP Connect (IMRN)- 



-7. lAM (IMRN)- 



8. Translate IMRN 
in VCC AS PSI 



-29. ACM- 



-31.ANM- 



VCCAS 

gsmSCF 

/CCCF 



CDF 



4. Detects this is 

VCC User so 

reroutes call to IMS 



9. SIP INVITE (VCC AS 
PSI, Call ID#1) 



10. Anchoring 
Decision 



11. SIP INVITE 
I (B Party, - 

Call ID#2) 
12. SIP INVITE (B Party, Call ID#2)- 



S-CSCF 



-14. SIP 200 OK- 



-15. ACRStart- 



13. Normal Call 

Control, Service 

Triggering & 

Charging 



16. Open S-CSCF 

CDR for Remote leg 

(Call ID#2) 



-17. ACA- 



-18. SIP200OK» 



— 19. ACR Start! 



-22. SIP 200 OK- 



-26. ACR Start- 



-28. ACA- 



20. Open VCC AS 

CDR for Remote leg 

(Call ID#2) 



I — 21 . ACA 

-23.ACRStart» 



24. Open VCC AS 

CDR for Access leg 

(Call ID#1) 



-25. ACA- 



27. Open VCC 

IVIGCFCDRfor 

Access leg (Call 

ID#1) 



Figure 5.2.2. 1.13.2-C: IVIessage Sequence Chart VCC UE originating call from CS and Domain 

Transfer CS to IIUIS 
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1. The VCC User (UE-1) originates a voice call in the CS domain. 

2. The originating call is processed in the CS network according to CS origination procedures. The user 
profile is retrieved from the HLR with the CAMEL Detection points for VCC. 

3. A CAP Initial DP message is sent to the VCC AS to get instructions on how to process the call. 

4. The VCC application detects that the user is an IMS user in the CS-domain, so reroutes the call to 
IMS for anchoring. 

5. It responds with a CAP connect containing the IMS Routing Number (IMRN). 

6. The MSC opens a MOC Record as defined in 3GPP TS 32.250 [2]. 

7. The VMSC routes the call towards the user"s home IMS network via an MGCF in the home network. 

8. The VCC AS PSI DN is resolved using the IMRN. 

9. The MGCF initiates an INVITE towards the VCC AS in the home IMS of the originating VCC user. 
This message is routed based on one of the standard procedures specified for PSI based Application 
Server Termination. 

10. The VCC call is anchored at the VCC AS in the home IMS Domain upon reception of the SIP Invite 
(Call Id#l) 

11. and 12. The AS forwards the INVITE request message to the terminating network (Call Id#2) via the S-CSCF 

in the originating network. 

13. The terminating network performs call control, service triggering for the incoming call as usual. (This 
is shown in more detail in the first figure in section 15.2.2.1.13.1.) 

14. The final response 200 OK is transmitted to the S-CSCF in the Originating network. 

15. Upon reception of the final response, the S-CSCF in the originating network sends an Accounting- 
Request with Accounting-Record-Type indicating START_RECORD to record VCC call routing and 
start of a user session/media component in the S-CSCF CDR. 

16. and 17. The CDF from the Originating network opens an S-CSCF CDR related to the Remote leg and 

acknowledges the reception of the data. 
18 The final response 200 OK is transmitted to the VCC AS. 

19. Same as 15 but for VCC AS (Remote leg) 

20. and 21. Same as 16 and 17 but opening a VCC AS CDR related to the Remote leg. 

22. The final response 200 OK is transmitted from the VCC AS to the MGCF for the Access leg. 

23. Same as 19. but for VCC AS (Access leg). 

24. and 25. Same as 20 and 21 but for the VCC AS CDR (Access leg). 

26. Same as 19. but for the MGCF (Access leg) 

27. and 28. Same as 20. and 21. but opening a MGCF CDR (Access leg) 

28. The final response to SIP Invite (Call Id#l) is received by the UE-1 

29. 30, 31. & 32. The MGCF completes the establishment of the Access Leg using normal ISUP & CS procedures. 
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D. Domain Transfer from CS to IMS 



Originating UE-1 (VCC User) Home network 



Terminating UE-2 home 
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-35. SIP 200 OK- 
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S-CSCF 
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— 38. ACA- 
-39. ACR Start 



40. Open S-CSCF 

CDR tor new Access 

leg (Call ID#1') 



-41.ACA- 



-47. SIP BYE- 



-52. ACR Stop- 



-54. ACA- 



-42. SIP UPDATE (Call ID#2)- 
43. SIP 200 OK 



-44. ACR Interim 



1 



45. Update VCC AS 

CDR for Remote leg 

(Call ID#2) 



-46. ACA- 



-4g.ACRStopl 



50. Close VCC AS 

CDR for original 

Access leg (Call 

ID#1) 



-51. ACA- 



53. Close MGCF CDR 

for original Access leg 

(CalllD#1) 



Figure 5.2.2. 1.13.2-D: Message Sequence Chart VCC UE originating call from CS and Domain 

Transfer CS to IMS (Continued) 



33. 



34. 
35. 
36. 



37. and 38. 



The VCC User (UE-1) originates a voice call in the IMS domain using the VCC Domain Transfer 

URI (VDI) to establish an Access Leg via the IMS domain and request Domain Transfer of the active 

CS session to IMS. 

The home S-CSCF routes the call to the VCC AS. 

The VCC AS responds with a final response which is sent back to the UE. 

Upon generation of the final response, the VCC AS in the home IMS of the originating VCC user 

sends an Accounting-Request with Accounting-Record-Type indicating START_RECORD to record 

start of a user session in the VCC AS CDR. 

The CDF opens an VCC AS CDR and acknowledges the reception of the data. 
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39. Same as 36, but for S-CSCF in the originating network. 

40. and 41. Same as 37 and 38 open the S-CSCF CDR in the originating network. 

42. and 43. The VCC AS performs the Domain Transfer by updating the Remote Leg with the connection 

information of the newly established Access Leg using the Access Leg Update procedure toward 
remote end. It sends an UPDATE message. The new SDP in the UPDATE message indicates that the 
IP address towards the VCC UE is changed: the IP address that was previously the IP address of the 
VCC UE is changed into the IP address of the MGW. The new bearer path goes now from the VCC 
UE to the IM-MGW and then to the other end-point network. 

44. At Access Leg update the VCC AS sends Accounting-Request with Accounting-Record-Type 
indicating INTERIM_RECORD to record update of a session in the VCC AS CDR. 

45. and 46. The CDF updates the VCC AS CDR and acknowledges the reception of the data. 
47. and 48. The original access leg, previously established over CS is released. 

49. At session termination the VCC AS sends Accounting-Request with Accounting-Record-Type 
indicating STOP_RECORD to record stop of a session and stop of a media component in the VCC AS 
CDR. This CDR may be generated with special handling. One example of special handling is to zero 
rate the IMS resource usage for the Access leg establishment. This can be performed using the 
"Service Specific Data" parameter in the VCC AS CDR indicating the anchoring of a VCC call. 

50. and 5 1 . The CDF closes the AS CDR for the initial Access leg and acknowledges the reception of the data 

52. Same as 49, but for MGCF. 

53. and 54. Same as 50. and 51. closing the MGCF CDR related to the initial Access leg. This CDR may be 

generated with special handling. One example of special handling is to zero rate the IMS resource 
usage for Access leg establishment. This can be performed using the correlation mechanism with the 
VCC AS CDR for Access leg. 
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5.2.2.1 .14 Initiating Alternate Charged Party Call 

The following figure shows the case where a call with an alternate charged party is successfully initiated. 



AS 



CDF 



SIP signalling 



1. Invite 



AS determines via an 

internal process that it is 

OK to initiate an Alternate 

Party Charged call for a 

served subscriber. 




2. Invite 



3. 200 OK (Answer) 



5. Accounting Request [Slart] 



Open an AS CDR 



6. Accounting Answer 



More SIP Signaling 




SIP Session Established 



Figure: Successful Initiation of Alternate Party Charging 

1 . The AS receives a SIP Invite. 

2. After determining that Alternate Charged Party is supported, the AS initiates an Invite with an "Alternate Party Identity" for charging. The 
method for determination of the alternate charged party includes accessing subscriber data and doing a security assessment. 

3. The terminating side issues a 200 OK (Answer), to AS. 

4. The AS sends a 200 OK. 

5 . The AS sends an accounting request to the CDF. 

6. The CDF opens a CDR with the Subscription-ID for the Alternate Charged Party and sends an accounting answer to the AS. 

7. The session is established. 
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5.2.2.2 Message Flows - Error Cases and Scenarios 

This clause describes various error cases and how these should be handled. The error cases are grouped into the 
following categories: 

• Failure in SIP Related Procedures; 

Session Related Error Scenarios; 
Session Unrelated Error Scenarios. 

• Errors in Diameter (Accounting) Related Procedures. 

5.2.2.2.1 Session Related SIP Procedures- Reception of SIP error messages 

A SIP session is closed abnormally by the reception of a BYE message indicating the reason for such termination. 
In this case, an ACR [Stop] message that includes an appropriate error indication is sent. 

5.2.2.2.2 Session Related SIP Procedures - SIP session failure 

AH nodes involved in the SIP session are expected to exercise some kind of session supervision. In case a node detects 
an error in the SIP session, such as a timeout or the occurrence of an invalid SIP message that results in the inability to 
maintain the session, this IMS node will generate a BYE message towards both ends of the connection. 

The node that sent the BYE to trigger session termination identifies the cause of the failure in the ACR [Stop] towards 
the CDF. All other nodes, i.e. those that receive the BYE, are not aware of an error, and therefore they treat this 
situation as any normal SIP session termination. 

5.2.2.2.3 Session Unrelated SIP procedures 

As described in clause 5.1.2.1.2, a session unrelated SIP procedure may either be completed with the reception of a 
200OK, or a SIP error message. If the latter occurs, i.e. there is a failure in the procedure, the ACR [Event] sent towards 
the CDF includes an appropriate error indication. 

5.2.2.2.4 CDF Connection Failure 

When the connection towards the primary CDF is broken, the process of sending accounting information should 
continue towards a secondary CDF (if such a CDF is configured). For further CDF connection failure functionality, see 
clause "Transport Failure Detection" in IETF RFC 3588 [401]. 

If no CDF is reachable the network element may buffer the generated accounting data in non-volatile memory. Once the 
CDF connection is working again, all accounting messages stored in the buffer is sent to the CDF, in the order they 
were stored in the buffer. 

5.2.2.2.5 No Reply from CDF 

In case an IMS node does not receive an ACA in reply to an ACR, it may repeat the ACR message. The waiting time 
until a repetition is sent, and the maximum number of repetitions are both configurable by the operator. When the 
maximum number of repetitions is reached and still no ACA reply has been received, the IMS node executes the CDF 
connection failure procedure as specified above. 

If retransmitted ACRs are sent, they are marked with the T-flag as described in IETF RFC 3588 [401] , in order to allow 
duplicate detection in the CDF, as specified in the next clause. 

5.2.2.2.6 Duplicate Detection 

A Diameter client marks possible duplicate request messages (e.g. retransmission due to the link failover process) with 
the T-flag as described in IETF RFC 3588 [401]. 

If the CDF receives a message that is marked as retransmitted and this message was already received, then it discards 
the duplicate message. However, if the original of the re-transmitted message was not yet received, it is the information 
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in the marked message that is taken into account when generating the CDR. The CDRs are marked if information from 
duphcated message(s) is used. 

5.2.2.2.7 CDF Detected Failure 

The CDF closes a CDR when it detects that expected Diameter ACRs for a particular SIP session have not been 
received for a period of time. The exact behaviour of the CDF is operator configurable. 

5.2.3 CDR generation 

Editor" s Note: FFS 

5.2.4 GTP" record transfer flows 

GTP" is not used between CDF and CGF in IP Multimedia subsystem, because CDF and CGF are combined into CCF 
(see clause 4). 

Text should be copied from the middle tear template section. 

5.2.5 Bi CDR file transfer 

Editor" s Note: FFS 

5.3 IMS Online Charging Scenarios 
5.3.1 Basic Principles 

IMS online charging uses the Credit Control application that is specified in 3GPP Rel-6 TS 32.299 [50]. 
Three cases for online charging are distinguished: 

• Immediate Event Charging (lEC); and 

• Event Charging with Unit Reservation (ECUR), and 

• Session Charging with Unit Reservation (SCUR) 

Both stage 2 and stage 3 mechanisms for the three cases for online charging are detailed in TS 32.299 [50]. 

In the case of Immediate Event Charging (lEC), granting units to the IMS network element is performed in a single 
operation that also includes the deduction of the corresponding monetary units from the subscriber's account. The 
charging process is controlled by the corresponding credit control request which is sent for a given credit control event. 

In contrast. Event Charging with Unit Reservation (ECUR) also includes the process of requesting, reserving, releasing 
and returning unused units for events. The deduction of the corresponding monetary units then occurs upon conclusion 
of the ECUR transaction. In this case, the credit control request is used to control the credit control session. 

Session Charging with Unit Reservation (SCUR) is used for credit control of sessions. SCUR also includes the process 
of requesting, reserving, releasing and returning unused units for sessions, and the deduction of the corresponding 
monetary units. During a SIP session there can be repeated execution of unit reservation and debit operations as 
specified in TS 32.299 [50]. 

The IMS network element may apply lEC, where CCR Event messages are generated, or ECUR, using CCR Initial, and 
Termination or SCUR. The decision whether to apply lEC, ECUR or SCUR is based on the service and/or operator's 
policy. 

The CTF uses CCR Initial, Update, Terminate in procedures related to successful SIP sessions. It uses CCR Events for 
unsuccessful SIP sessions and for session unrelated procedures. Further details are specified in the tables below. 

It is operator configurable in the nodes for which SIP method a Credit Control Request is sent. The table below 
describes aU possible CCRs that might be sent from a S-CSCF. 
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It is configurable for the operators to enable or disable the generation of a CCR message by the IMS node in response to 
a particular "Triggering SIP Method". 



Table 5.3.1.1 : Credit Control Request Messages Triggered by SIP Methods for IMS-GWF 



Diameter 
IVIessage 



Triggering SIP Method 



CCR [Initial] 



SIP INVITE (SCUR) 



SIP NOTIFY (ECUR) 



SIP IVIESSAGE (ECUR) 



SIP REGISTER (ECUR) 



SIP SUBSCRIBE (ECUR) 



SIP REFER (ECUR) 



SIP PUBLISH (ECUR) 



CCR [Update] 



SIP 200 OK acl<nowledging a SIP INVITE, RE-INVITE or SIP UPDATE [e.g. cliange in media 
components] (SCUR) 



RE-INVITE or SIP UPDATE [e.g. cliange in media components] (SCUR) 



Expiration of quota, Validity time expiry or other autliorization triggers (quota tlireshold reached, 
(SCUR) 



Any SIP message (except those triggering a CCR INITIAL or those not covered by the above triggers 
for CCR UPDATE) conveying a SDP offer or its associated SDP answer before SIP session 
establishment (SCUR) 



CCR 
[Terminate] 



SIP BYE message (both normal and abnormal session termination cases) (SCUR) 



SIP 200 OK acl<nowledging non-session related SIP messages (ECUR) 



Aborting a SIP session set-up procedure, using an internal trigger, or a SIP CANCEL.(SCUR/ECUR) 
Deregistration (see NOTE) (SCUR/ECUR) 



SIP Final Response 2xx (including 202 response to REFER, except SIP 200 OK) (ECUR) 
SIP Final/Redirection Response 3xx (SCUR/ECUR) 



SIP Final Response (4xx, 5xx or 6xx), indicating an unsuccessful SIP session set-up procedure 
(SCUR) 



SIP Final Response (4xx, 5xx or 6xx), indicating an unsuccessful session-unrelated procedure 
(ECUR) 



CCR [Event] 



SIP NOTIFY (lEC) 



SIP IVIESSAGE (lEC) 



SIP REGISTER (lEC) 



SIP SUBSCRIBE (lEC) 



SIP REFER (lEC) 



SIP PUBLISH (lEC) 



SIP Final Response (4xx, 5xx or 6xx), indicating an unsuccessful session-unrelated procedure (lEC) 



NOTE : SIP SUBSCRIBE with the field "Expires" set to means unsubscribe. SIP REGISTER with its "Expires" 

header field or "Expires" parameter equal to or local deregistration due to expiry means Deregistration (see 
3GPP TS 24.229 [204]). 



Table 5.3.1.2: Credit Control Request messages triggered by SIP Methods for MRFC 



Diameter 
Message 


Triggering SIP Method 


CCR [Initial] 


SIP INVITE(SCUR) for initiating a multimedia ad hoc conferencing session 


CCR [Update] 


SIP RE-INVITE or SIP UPDATE[e.g. change in media components](SCUR) 


SIP BYE message 


Expiration of AVP[Acct-lnterim-lnterval](SCUR) 


CCR [Terminate] 


SIP BYE message(both normal and abnormal session termination cases)(SCUR) 


SIP Final Response with error codes 4xx, 5xx or 6xx indicating termination of an ongoing 
session(SCUR) 


SIP CANCEL(SCUR) 


CCR [Event] 


SIP Final/Redirection Response 3xx 


SIP Final Response with error codes 4xx, 5xx or 6xx indicating termination of an ongoing 
session(IEC) 


SIP CANCEL, indicating abortion of a SIP session set-up 


SIP REFER(IEC) 


SIPSUBSCRIBE(IEC) 



Editors Note: Triggers for AS are FFS. 
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NOTE: To the extent possible alignment with the IETF RFC 4006 [402] is planned. 
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5.3.2 Diameter Message Flows and Types 

This clause describes the message flows for the event charging procedures on the Ro interface. 

5.3.2.1 Immediate Event Charging (lEC) 

This clause provides the details of the "Debit Units" operation specified in TS 32.299 [50]. 

5.3.2.1 .1 Message Flows - Successful Cases and Scenarios 

5.3.2.1 .1 .1 lEC - Debit Units Operation 

The transactions that are required on the Ro interface in order to perform lEC with Debit Units operations are carried 
out as described in TS 32.299 [50] where 'CTF' refers to IMS network element. The Debit Units operation may 
alternatively be carried out prior to, concurrently with or after service/content delivery. The IMS network element must 
ensure that the requested service execution is successful, when this scenario is used. 

Editor"s Note: Must be aligned with TS 32.299 [50]. 
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5.3.2.1.1.2 



Scenarios 



The following figure shows the Diameter credit control transactions that are required between the IMS-GWF and the 
OCS for session-unrelated IMS procedures, i.e. those that relate to the CCR [Event], as listed in Table 5.3.1. 

SIP messages and Diameter transactions associated with these charging scenarios are shown primarily for general 
information and to illustrate the charging triggers. They are not intended to be exhaustive and depend on the Diameter 
Credit Control Requests triggers configured by the operator. 

Scenario 1 : Successful session unrelated case 

NOTE: The Debit Units operation is carried out prior to service/content delivery. 



S-CSCF 



1. SIP Request (e.g. SUBSCRIBE) 



IMS-GWF 



1. SIP Request (e.g. SUBSCRIBE) 



OCS 



Service control 



4. SIP Request (e.g. SUEiSCRIBE) 



4. SIP Request 



2. Debit Unit Request [Event] 



Credit control 



3. Debit Unit Response [Event] 



(e.g. SUBSCRIBE) 



1) A session unrelated SIP Request (e.g. SUBSCRIBE) is received in the S-CSCF. The S-CSCF forwards this 
request to the IMS-GWF. 

2) The IIVIS-GWF sends a Debit Unit Request (CC-Request-Type=EVENT_REQUEST) to the OCS, requesting 
units in order to provide the service. 

3) The OCS sends the Debit Unit Response to acl<nowledge the Debit Unit Request, granting the requested 
units. 

4) The IIVIS-GWF and the S-CSCF forward the SIP Request. 

Figure Scenario 1 : Message Sequence Chart for Session-Unrelated Procedure 

5.3.2.1 .2 Message Flows - Error Cases and Scenarios 

This clause describes various error cases and how these should be handled. 

The failure handling behaviour is locally configurable in the IMS network element. If the Direct-Debiting-Failure- 
Handling AVP is not used, the locally configured values are used instead. 



5.3.2.1.2.1 



Reception of SIP Error Messages 



If SIP errors in SIP response (4xx, 5xx or 6xx) occur during service delivery, as defined in TS 24.228 [202] and TS 
23.218 [203], it is up to the IMS network element to determine to what extent the service was delivered before the error 
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occurred and act appropriately with respect to charging. This may imply that no units at all (or no more units) are 
debited. 

5.3.2.1 .2.2 Debit Units Operation Failure 

This case comprises situations where either no, or an erroneous response, is received from the OCS. The 'no response' 
case is detected by the IMS network element when the connection supervision timer Tx expires (IETF RFC 4006 [402]) 
before a response Credit-Control-Answer (CCA) is received. The case of receiving an erroneous response implies that 
the IMS network element receives a Credit-Control-Answer (CCA), which it is unable to process, while Tx is running. 
The failure handling complies with the failure procedures for "Direct Debiting" scenario described in IETF RFC 4006 
[402]. 

5.3.2.1.2.3 Duplicate Detection 

The detection of duplicate request is needed and must be enabled. To speed up and simplify as much as possible the 
duplicate detection, the all-against-all record checking should be avoided and just those records marked as potential 
duplicates need to be checked against other received requests (within a reasonable time window) by the receiver entity. 

The IMS network element marks the request messages that are retransmitted after a link failover as possible duplicates 
with the T-flag as described in [201]. For optimized performance, uniqueness checking against other received requests 
is only necessary for those records marked with the T-flag received within a reasonable time window. This focused 
check is based on the inspection of the Session-Id and CC-Request-Number AVP pairs. 

5.3.2.2 Event Charging with Unit Reservation (ECUR) and Session Charging with 

Unit Reservation (SCUR) 

This clause provides the details of the "Reserve Units" and "Debit Units" operation specified in TS 32.299 [50]. 

5.3.2.2.1 Message Flows - Successful Cases and Scenarios 

5.3.2.2.1 .1 ECUR and SCUR - Reserve Units and Debit Units Operations 

The transactions that are required on the Ro interface in order to perform ECUR/SCUR with Reserve Units and Debit 
Units operations is carried out as described in TS 32.299 [50] where 'CTF' refers to an IMS network element. Multiple 
replications of both of these operations are possible. 

5.3.2.2.1.2 Expiration of Reservation Validity 

This clause defines how reserved units are returned, if not used, within a reasonable time. It should be possible that 
both, reservation and SIP sessions are cancelled or only the reservation is cancelled without removing the SIP session. 

5.3.2.2.1.3 Scenarios 

The following figure shows the Diameter credit control transactions that are required between the IMS-GWF and the 
OCS for session-related and session-unrelated IMS procedures. 

The SIP messages and Diameter transactions associated with these charging scenarios are shown primarily for general 
information and to illustrate the charging triggers. They are not intended to be exhaustive and they depend on the 
Diameter Credit Control Requests triggers configured by the operator. 
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5.3.2.2.1 .3.1 Session Related Procedures (SCUR). 

Scenario 1: Successful Session Establishment 

The following figure shows the Diameter credit control transactions that are required in the IMS-GWF during a SIP 
session establishment. 



S-CSCF 



IMS-GWF 



1. INVITE 



1. INVITE 



DCS 









Service control 




litial] 










2. Reserve Unit Request [1 






4. INVITE 




'^ 








Credit control 






3. Reserve Unit Respons 


e [Initial] 














4. INVITE 










\ 



More SIP signalling and optionally more Reserve Unit Requests 



5. 200 OK (Invite) 



5. 200 OK (Invite) 



Service control 

6. Reserve Unit Request [Update] 



8. 200 OK (Invite) 



8. 200 OK (Invite) 



Credit control 



7. Reserve Unit Response [Update] 



1) An initial SIP Invite Request is received in the S-CSCF. This request is forwarded to the IMS-GWF. 

2) The IMS-GWF sends a Reserve Unit Request (CC-Request-Type =INITIAL_REQUEST) to the DCS 
requesting service units. The online credit control session is initiated. 

3) The OCS grants units in the Reserve Unit Response. 

4) The IMS-GWF and S-CSCF forward the initial INVITE. 

5) A final response is received in the IMS-GWF. 

6) If the trigger is active, the 200 OK answer triggers a Reserve Unit Request (CC-Request-Type 
=UPDATE_REQUEST) in the IMS-GWF in order to update the credit control session. New service units are 
requested. Also the used service units (if any) are reported. 

7) The OCS sends the Reserve Unit Response to acknowledge the Reserve Unit Request. New service units 
are granted. 

8) The final answer is forwarded. 

Figure Scenario 1 : IVIessage Sequence Chart for Successful Session Establishment 
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Scenario 2 : Successful Session Establishment with Early Media Negotiation 

The following figure shows the Diameter transactions that are required in the IMS-GWF during a SIP session 
establishment in which SDP negotiation is completed before a final response to the initial INVITE is exchanged. 



1. SIP INVITE (SDP offer) 



S-CSCF 



IMS-GWF 



ocs 



Non final SIP Response 
(SDP Answer) 



1. SIP INVITE (SDP offer) 



Service control 



4. SIP INVITE (SDP offer) 



4. SIP INVITE (SDP offer) 



2. Reserve Unit Request [Initial] 



Credit control 



3. Reserve Unit Responss [Initial] 



5. Non final SIF' Response (SDP Answer) 



5. Non final SIP Respons e (SDP Answer) 
Service control 

6. Reserve Unit Request [lllpdate] 



Non final SIP Response 
(SDP Answer) 



Credit control 
7. Reserve Unit Response [Update] 



IVIore SIP signalling and optionally more Reserve Unit Requests before INVITE final response 



1) An initial SDP offer is conveyed in a SIP INVITE message. The SIP INVITE message received in the S- 
CSCF is forwarded to the IIVIS-GWF. 

2) In this example, the SDP offer is conveyed in a SIP request which implies the start of the online session 
towards the OCS. The IMS-GWF sends a Reserve Unit Request (GG-Request-Type =INITIAL_REQUEST) 
to the OGS requesting service units. The online credit control session is initiated. 

3) The OGS grants units in the Reserve Unit Response. 

4) The IMS-GWF and S-GSGF forward the SIP Request conveying the SDP offer. 

5) A non-final SIP message (e.g. a provisional reliable response) conveying an SDP answer is received in the 
IMS-GWF. 

6) The received SDP answer triggers a Reserve Unit Request (CC-Request-Type =UPDATE_REQUEST) in 
order to update the credit control session. New service units are requested. Also the used service units (if 
any) are reported. 

7) The OGS sends the Reserve Unit Response to acknowledge the Reserve Unit Request. New service units 
are granted. 

8) The SDP answer is forwarded. 

Figure Scenario 2 : lUlessage Sequence Chart for Session Establishment with Early Media Negotiation 
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Scenario 3 : Mid-Session Procedures 

The figure shows the Diameter transactions that are required in the IMS-GWF when receiving a SIP Re -INVITE in 
mid-session, e.g. in order to modify media component(s), or when the hold and resume procedure is executed. 



S-CSCF 



IMS-GWF 



OCS 

(home) 



Ongoing SIP Session 



1. RE-INVITE 



1. RE-INVITE 



Service control 



4. RE-INVITE 



4. RE-INVITE 



2. Reserve Unit Request [Update] 



Credit control 



3. Reserve Unit Response 



[Update] 



More SIP signalling 



8. 200 OK (RE-INVITE) 



5. 200 OK (RE-INVITE) 



5. 200 OK (RE-INVITE) 



Service control 



8. 200 OK (RE-INVITE) 



6. Reserve Unit Request [Update] 



Credit control 
7. Reserve Unit Response [Update] 



1) 
2) 



3) 
4) 
5) 
6) 



7) 
8) 



A SIP RE-INVITE request is received in the S-CSCF. This request is forwarded to the IMS-GWF. 

Upon receiving the SIP RE-INVITE request, the IIVIS-GWF sends a Reserve Unit Request (CC-Request-Type 

= UPDATE_REQUEST) to update the previously initiated credit control session. New service units are 

requested. The used service units (if any) are also reported. 

The OCS grants new service units in the Reserve Unit Response. 

The RE-INVITE request is forwarded. 

The RE-INVITE request is acknowledged with a 200 OK. 

If the trigger is active, the IMS-GWF sends a Reserve Unit Request (CC-Request-Type 

=UPDATE_REQUEST) to the OCS to update the credit control session. New service units are requested. 

The used service units (if any) are also reported. 

The OCS grants new service units in the Reserve Unit Response. 

The 200 OK message is forwarded. 

Figure Scenario 3 : lUlessage Sequence Chart for lU! id-Session Procedures 
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Scenario 4: Session Release 

The following figure shows the Diameter transactions that are required in the IMS-GWF for a session release scenario. 



S-CSCF 



IMS-GWF 



OCS 



Ongoing SIP Session 



1. BYE 



1. BYE 



Service control 



2. BYE 



5. 200 OK 



5. 200 OK 



5. 200 OK 



2. BYE 



3. Reserve Unit Request [Termination] 



Credit control 



4. Reserve Unit Response [Termination] 



5. 200 OK 



1 ) A SIP session is released by sending a SIP BYE message. The S-CSCF forwards this message to the IMS- 
GWF. 

2) Upon receiving the BYE message, the IMS-GWF forwards the SIP BYE request to the UE. 

3) In case there is an ongoing online control session, the IMS-GWF sends a Reserve Unit Request (CC- 
Request-Type =TERMINATION_REQUEST) reporting the used granted units. 

4) The OCS sends a Reserve Unit Response. The online credit control session is terminated. 

5) The final answer to the Bye message is forwarded. 

Figure Scenario 4 : IVIessage Sequence Chart for Session Release. 
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5.3.2.2.1 .3.2 Session Unrelated Procedures (ECUR). 

Scenario 1: Successful session unrelated procedure 

The following figure shows the Diameter transactions that are required in the IMS-GWF for a session unrelated 
procedure. 



S-CSCF 



IMS-GWF 



OCS 



1 . SIP Request (e.g. SUBSCRIBE) 



1 . SIP Request (e.g. SUBSCRIBE) 



Service control 



4. SIP Request (e.g. SUEiSCRIBE) 



4. SIP Request (e.g. SUEiSCRIBE) 



2. Reserve Unit Request [Initial] 



Credit control 



3. Reserve Unit Response 



Initial] 



More SIP signalling 



8. SIP Response 



5. SIP Response 



5. SIP Response 



Service control 



8. SIP Response 



6. Reserve Unit Request |Termination] 



Credit control 
7. Reserve Unit Response [Ternnination] 



1) A session unrelated SIP Request (e.g. SUBSCRIBE) is received in the S-CSCF. The S-CSCF forwards this 
to t request he IMS-GWF. 

2) The IMS-GWF sends a Reserve Unit Request (CC-Request-Type = INITIAL_REQUEST) to initiate a credit 
control session. Service units are requested to the OCS. 

3) The OCS grants service units in the Reserve Unit Response. 

4) The IMS-GWF and the S-CSCF forward the SIP Request 

5) Depending on the used SIP method, there might be additional signalling between steps 4 and 5. 

6) The SIP Request is acknowledged by a SIP Response. 

7) The IMS-GWF sends a Reserve Unit Request (CC-Request-Type=TERMINATION_REOUEST) to the OCS. 
It also reports the used granted units. 

8) The OCS sends a Reserve Unit Response to acknowledge the Reserve Unit Request. The online credit 
control session is terminated. 

9) The IMS-GWF and S-CSCF forward the SIP Response. 

Figure Scenario 1 : IVIessage Sequence Chart for Session-Unrelated Procedures 



£75/ 



3GPP TS 32.260 version 7.7.0 Release 7 49 ETSI TS 1 32 260 V7.7.0 (201 0-04) 

5.3.2.2.2 Message Flows - Error Cases and Scenarios 

This clause describes various error cases and how these should be handled. 

The failure handling behaviour is locally configurable in the IMS network element. If Credit-Control-Failure-Handling 
AVP is not used, the locally configured values are used instead. 

5.3.2.2.2.1 Reception of SIP Error Messages 

If SIP errors occur during service delivery, as defined in [202] and [203], it is up to the IMS network element to 
determine to what extent the service was delivered before the error occurred and act appropriately with respect to 
charging. This may imply that no units at all (or no more units) are reserved or debited. 

5.3.2.2.2.2 Reserve Units and Debit Units Operation Failure 

This case comprises of OCS connection failure, and/or receiving error responses from the OCS. 

The IMS network element detects an OCS connection failure when the timer Tx expires (IETF RFC 4006 [402]) or a 
transport failure is detected as defined in IETF RFC 3588 [401]. The OCS also has the capability to detect failures when 
the timer Ts (IETF RFC 3588 [401]) expires. The OCS should indicate the cause of failure by setting the appropriate 
result code as defined in IETF RFC 3588 [401] and IETF RFC 4006 [402]. In any case, the failure handling of IMS 
network element and OCS complies with the failure procedures for session based credit control scenario described in 
IETF RFC 4006 [402]. 

5.3.2.2.2.3 Duplicate Detection 

For credit control duplicate detection is performed only for possible duplicate event requests related to lEC as 
mentioned in clause 5.3.2.1.2.3, as retransmission of ECUR/SCUR related credit control requests is not allowed. 

5.3.2.2.2.4 Aborted Session Setup 

If a trigger occurs during session establishment to release a session during the establishment procedure, the IMS 
Network Element shall initiate procedures to cancel the session establishment as defined in TS 24.229 [204]. 
On completion of the cancellation procedure, the IMS Network Element shall close the credit-control session (for 
SCUR and ECUR) indicating an appropriate cause code. 

5.3.2.3 IMS Service Termination by OCS 

Annex C describes several scenarios related to IMS service termination. 

For IMS session related scenarios charged by means of SCUR in the IMS-GWF, Service Termination shall imply the 
rejection of a request for IMS session establishment or the release of an established session that is possibly associated to 
an online Diameter Charging Session. 

For IMS session unrelated scenarios charged by means of ECUR in the IMS-GWF, Service Termination shall imply the 
rejection of the SIP method triggering the Reserve Unit Request as defined in TS 32.299 [50]. 

For IMS session unrelated scenarios charged by means of lEC prior to service/content delivery in the IMS-GWF, 
Service Termination shall imply the rejection of the SIP method triggering the Debit Unit Request as defined in 
TS 32.299 [50]. 

5.3.2.3.1 Triggers on Ro interface which imply the termination of the IMS service 

The procedures in Ro interface which may trigger the IMS Service termination are the following: 

Reception of an unsuccessful Operation Result different from 

DIAMETER_CREDIT_CONTROL_NOT_APPLICABLE (TS32.299 [50]) in the Debit and Reserve Unit 
Response message. 

Reception of an unsuccessful Result Code different from 
DIAMETER_CREDIT_CONTROL_NOT_APPLICABLE (TS32.299 [50]) within the Multiple Unit 
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Operation in the Debit and Reserve Unit Response message when only one instance of the Multiple Unit 
Operation field is used. 

Execution of the Termination Action procedure as defined in TS32.299 [50] when only one instance of the 
Multiple Unit Operation field is used. 

Execution of the Failure Handling Procedures when the Failure Action is set to "Terminate" or "Retry & 
Terminate". 

Reception in the IMS-GWF of an Abort-Session-Request Message from OCS. 

In case either a Final-Unit-Indication or an erroneous Result-Code at Multiple Unit Operation level trigger the IMS 
service termination and the charging is based on ECUR or SCUR, the IMS-GWF shall close the Diameter online 
session by sending a Debit Units and Reserve Units operation of Type "Termination". 

Refer to TS 32.299 [50] for a detailed description of these procedures. 

5.3.2.3.2 Indication to the UE of the reason for IMS service release 

As a result of Service Termination triggering in IMS-GWF, the IMS service shall be denied to end-users. The network 
should provide an indication to UEs of the reason the service has been released or rejected. The procedure shall depend 
on: 

The charged party. 

The network should provide UEs with an indication of the reason the service has been released or rejected. 
However, this reason shall depend on whether the UE is the charged party or not. The premise is that only the 
charged party should know that the IMS service is being rejected / released because of OCS interaction. 

IMS specific protocol issues as defined in TS 24.229 [204]. 

A) The IMS-GWF generates a non-2xx final SIP response as a result of the IMS Service Termination 
procedure: 

In this scenario, the Response Code of the SIP response shall indicate the server understood the request but 
is refusing to fulfil it and that this request should not be repeated. The SIP response may include additional 
information about the cause to reject/release the IMS service. The presence of this additional error 
information in the response shall be operator configurable. 

The additional information included in the SIP response may contain a SIP URI. The UE may treat the SIP 
URI as if it were a Contact in a redirect and generate a new INVITE, resulting, for example, in a recorded 
announcement session being established. 

B) The IMS-GWF generates a SIP request (e.g. SIP BYE or SIP CANCEL) as a result of the IMS Service 
Termination procedure: 

In this scenario, the IMS-GWF may include a "Reason" field in the request which provides additional 
information about the cause to reject/release the IMS service. The presence of this additional information in 
the request shall be operator configurable. 

In both scenarios, it shall also be operator configurable both per SIP Method and per Originating/Terminating 
side, the content of the additional error information sent to the UEs. This error information shall also be 
configurable based on the procedure in Ro interface which has triggered the release/rejection of the IMS service 
according to clause 5.3.2.3.1. In particular when the Service Termination is triggered by the reception of an 
unsuccessful Operation Result (different from DIAMETER_CREDIT_CONTROL_NOT_APPLICABLE as 
defined in TS 32.299 [50]) in the Debit and Reserve Unit Response message or the reception of an unsuccessful 
Result Code (different from DIAMETER_CREDIT_CONTROL_NOT_APPLICABLE as defined in 
TS 32.299 [50]) within the Multiple Unit Operation in the Debit and Reserve Unit Response message, the 
additional error information/reason shall also be configurable based on the Result Code received through Ro 
interface. 



£75/ 



3GPP TS 32.260 version 7.7.0 Release 7 



51 



ETSI TS 132 260 V7.7.0 (2010-04) 



6 Definition of charging information 

6.1 Data description for IMS offline charging 
6.1 .1 Rf Message contents 

The IMS nodes generate accounting information that can be transferred from the CTF to the CDF. For this purpose, 
IMS offline charging utilises the Charging Data Transfer that is specified in the 3GPP accounting application described 
in TS 32.299 [50]. 

The Charging Data Transfer operation employs the Charging Data Request and Charging Data Response messages. 
The following table describes the use of these messages for offline charging. 

Table 6.1.1 : Offline Charging Messages Reference Table 



Command-Name 


Source 


Destination 


Charging Data Request 


S-CSCF, l-CSCF, P-CSCF, MRFC, MGCF, BGCF, AS 


CDF 


Charging Data Response 


CDF 


S-CSCF, l-CSCF, P-CSCF, 
MRFC, MGCF, BGCF, AS 



6.1.1.1 



Charging Data-Request Message 



The following table illustrates the basic structure of a Diameter Charging Data-Request message as used for IMS 
offline charging. 

Table 6.1.1.1 : Charging Data Request Message Contents 



Field 


Category 


Description 


Session Identifier 


M 


Described in 32.299 [50] 


Originator Host 


M 


Described in 32.299 [50] 


Originator Domain 


M 


Described in 32.299 [50] 


Destination Domain 


M 


Described in 32.299 [50] 


Operation Type 


M 


Described in 32.299 [50] 


Operation Number 


M 


Described in 32.299 [50] 


Operation Identifier 


Om 


The field corresponds to the unique operation identification. 


User Name 


Oc 


Described in 32.299 [50] 


Operation Interval 


Oc 


TBD 


Origination State 


Oc 


TBD 


Origination Timestamp 


Oc 


This field contains the time when the operation is requested. 


Proxy Information 


Oc 


This field contains the parameter of the proxy. 


Route Information 


Oc 


This field contains the parameter of the route. 


Operation Token 


Om 


This field identifies the domain, subsystem, or service and release. 


Service Information 


Om 


This field holds the 3GPP specific IMS parameter, described in 6.3. 
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6.1.1.2 



Charging Data Response Message 



The following table illustrates the basic structure of a Diameter Charging Data Response message as used for IMS 
offline charging. 

Table 6.1.1.2: Charging Data Response Message Contents 



Field 


Category 


Description 


Session Identifier 


M 


This field identifies the operation session. 


Operation Result 


M 


This field identifies the result of the operation. 


Originator Host 


M 


This field contains the identification of the source point of the operation and the 
realm of the operation originator. 


Originator Domain 


M 


This field contains the realm of the operation originator. 


Operation Type 


M 


This field defines the transfer type: event for event based charging and start, 
interim, stop for session based charging. 


Operation Number 


M 


This field contains the sequence number of the transferred messages. 


Operation Identifier 


Om 


The field corresponds to the unique operation identification. 


User Name 


Oc 


The field contains the Private User Identity [201]. 


Operation Interval 


Oc 


TBD 


Origination State 


Oc 


TBD 


Origination Timestamp 


Oc 


This field contains the time when the operation is requested. 


Proxy Information 


Oc 


This field contains the parameter of the proxy. 



6.1 .2 GTP" message contents 

GTP" is used between CDF and CGF in IP Multimedia subsystem. 
Use text from middle tear template 

6.1 .3 CDR Description on tine Bi Interface 
6.1.3.1 CDR Field Types 

The following Standard CDR content and format are considered: 

S-CSCF-CDR generated based on information from the S-CSCF. 

I-CSCF-CDR generated based on information from the I-CSCF. 

P-CSCF-CDR generated based on information from the P-CSCF. 

BGCF-CDR generated based on information from the BGCF. 

MGCF-CDR generated based on information from the MGCF. 

MRFC-CDR generated based on information from the MRFC. 

AS -CDR generated based on information from the AS. 

The content of each CDR type is defined in the tables in clauses 6.1.3.3 to 6.1.3.9. For each CDR type the field 
definition includes the field name, category and description. The detailed field descriptions are provided in 
TS 32.298 [51]. 

Editor" s Note: Equipment vendors shall be able to provide all of the fields listed in the CDR content table in order to 
claim compliance with the present document. However, since CDR processing and transport consume 
network resources, operators may opt to eliminate some of the fields that are not essential for their 
operation. 

Editors note: Rephrase the above paragraph and ref to 32.240 

The CDF provides the CDRs at the Bi interface in the format and encoding described in TS 32.298 [51]. Additional 
CDR formats and contents may be available at the interface to the billing system to meet the requirements of the billing 
system, these are outside of the scope of 3GPP standardisation. 
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6.1.3.2 CDR Triggers 

6.1.3.2.1 Session Related CDRs 

Reflecting the usage of multimedia sessions IMS CDRs are generated by the CDF on a per session level. In the scope of 
the present document the term "session" refers always to a SIP session. The coherent media components are reflected 
inside the session CDRs with a media component container comprising of all the information necessary for the 
description of a media component. 

Accounting information for SIP sessions is transferred from the CTF involved in the session to the CDF using Charging 
Data Request Start, Interim and Stop messages. A session CDR is opened in the CDF upon reception of a Charging 
Data Request [Start] message. Partial CDRs may be generated upon reception of a Charging Data Request [Interim] 
message, which is sent by the network entity towards the CDF due to a session modification procedure (i.e. change in 
media). Session CDRs are updated, or partial CDRs are generated upon reception of a Charging Data Request [Interim] 
message, which is sent by the network entity due to expiration of the Charging Data Interim Interval. The CDF closes 
the final session CDR upon reception of a Charging Data Request [Stop] message, which indicates that the SIP session 
is terminated. Further details on triggers for the generation of IMS CDRs are specified in [1]. 

Accounting information for unsuccessful session set-up attempts may be sent by the CTF to the CDF employing the 
Charging Data Request [Event] message. The behaviour of the CDF upon receiving Charging Data Request [Event] 
messages is specified in clause 6.1.3.2.2. 

6.1.3.2.2 Session Unrelated CDRs 

To reflect chargeable events not directly related to a session the CDF may generate CDRs upon the occurrence of 
session unrelated SIP procedures, such as registration respectively de-registration events. Accounting information for 
SIP session-unrelated procedures is transferred from the IMS nodes involved in the procedure to the CDF using 
Charging Data Request [Event] messages. Session unrelated CDRs are created in the CDF in a "one-off" action based 
on the information contained in the Charging Data Request [Event] message. One session unrelated CDR is created in 
the CDF for each Charging Data Request [Event] message received, whereas the creation of partial CDRs is not 
applicable for session unrelated CDRs. The cases for which the IMS nodes send Charging Data Request [Event] 
messages are listed per SIP procedure in table 5.2.1.1 and table 5.2.1.2. 

Further details on triggers for the generation of IMS CDRs are specified in clause 5.2.2. 
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6.1 .3.3 S-CSCF CDR Content 

The detailed description of the field is provided in TS 32.298 [51]. 



Table 6.1.3.3: Charging Data of S-CSCF CDR 



Field 


Category 


Description 


Record Type 


M 


Identifies the type of record. The parameter is derived from the Node functionality 
parameter. 


Retransmission 


Oc 


This parameter, when present, indicates that information from retransmitted Charging 
Data Requests has been used in this CDR 


SIP Method 


Oc 


Specifies the SIP-method for which the CDR is generated. Only available in session 
unrelated cases. 


Event 


Oc 


This field identifies the SIP event package to which the SIP request is referred. 


Expires Information 


Oc 


This field indicates the validity time of either the SIP message or its content, 
depending on the SIP method. 


Role of Node 


Om 


This field indicates the role of the S-CSCF. 


Node Address 


Om 


This item holds the address of the node providing the information for the CDR. This 
may either be the IP address or the FODN of the IMS node generating the accounting 
data. 


Session ID 


Om 


The Session identification. For a SIP session the Session-ID contains the SIP Call ID 
as defined in the Session Initiation Protocol RFC 3261 [404]. 


List Of Calling Party 
Address 


Om 


The address or addresses (Public User ID or Public Service ID) of the party 
requesting a service or initiating a session. 


List of Associated 
URI 


Oc 


The list of non-barred public user identities (SIP URIs and/or TEL URIs) associated to 
the public user identity under registration. 


Called Party Address 


Om 


For SIP transactions, except for registration, this field holds the address of the party 

(Public User ID or Public Service ID) to whom the SIP transaction is posted. 

For registration transactions, this field holds the Public User ID under registration. 


Requested Party 
Address 


Oc 


For SIP transactions this field holds the address of the party (Public User ID or Public 

Service ID) to whom the SIP transaction was originally posted. 

This field is only present if different from the Called Party Address parameter. 


List of Called 
Asserted Identity 


Oc 


The address or addresses of the final asserted identities. Present if the final asserted 
identities are available in the SIP 2xx response. 


Private User ID 


Om 


Holds the used private user identity of the served party according to RFC2486 [405]. 


List of Subscription Id 


Om 


Holds the public user identities of the served user 


Service Request 
Time Stamp 


Om 


This field contains the time stamp, which indicates the time at which the service was 
requested. 


Service Delivery 
Start Time Stamp 


Om 


This field holds the time stamp reflecting either: successful session set-up, a delivery 
unrelated service, an unsuccessful session set-up and an unsuccessful session 
unrelated request. 


Service Delivery End 
Time Stamp 


Oc 


This field records the time at which the service delivery was terminated. It is Present 
only in SIP session related case. 


Record Opening 
Time 


Oc 


A time stamp reflecting the time the CDF opened this record. Present only in SIP 
session related case. 


Record Closure Time 


Om 


A Time stamp reflecting the time the CDF closed the record. 


Application Servers 
Information 


Oc 


This a grouped CDR field containing the fields: 'Application Server Involved' and 
'Application Provided Called Parties'. 


Application 
Servers Involved 


Oc 


Holds the ASs (if any) identified by the SIP URIs. 


Application 
Provided Called 
Parties 


Oc 


Holds a list of the Called Party Address(es), if the address(es) are determined by an 
AS (SIP URI, E.164...). 


List of Inter Operator 
Identifiers 


Oc 


Holds the identification of the home network (originating and terminating) if exchanged 
via SIP signalling, as recorded in the P-Charging-Vector header. This grouped field 
may occur several times in one CDR. 


Originating 101 


Oc 


This parameter corresponds to Orig-IOI header of the P-Charging-Vector defined in 
TS 24.229 [204]. 


Terminating 101 


Oc 


This parameter corresponds to Term-IOI header of the P-Charging-Vector defined in 
TS 24.229 [204]. 


Local Record 
Sequence Number 


Om 


This field includes a unique record number created by S-CSCF. The number is 
allocated sequentially for each partial CDR (or whole CDR) including all CDR types. 
The number is unique within the CDF. 


Record Sequence 
Number 


Oc 


This field contains a running sequence number employed to link the partial records 
generated by the CDF for a particular session. 
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Field 


Category 


Description 


Cause For Record 
Closing 


Om 


This field contains a reason for the close of the CDR. 


Incomplete CDR 
Indication 


Oc 


This field provides additional diagnostics when the CDF detects missing Charging 
Data Requests. 


IMS Charging 
Identifier 


Om 


This parameter holds the IMS charging identifier (ICID) as generated by the IMS node 
for the SIP session. 


List of Early SDP 
Media Components 


Oc 


This is a grouped field which may occur several times in one CDR. 

Each occurrence shall describe a change in the state (inactive/active or vice versa) of 

the media components negotiated during the SIP session establishment previously to 

the reception of a SIP final response to the initial SIP Invite. 

This field shall not be present if no media components are set to active before the final 

SIP session answer to the initial SIP Invite is received. 

This field can be present in either session or event CDRs. 


SDP Session 
Description 


Oc 


Holds the Session portion of SDP data exchanged in the above mentioned scenario, if 
available. 


SDP Offer 
Timestamp 


Om 


This parameter contains the time of the SIP Request which conveys the SDP offer. 


SDP Answer 
Timestamp 


Om 


This parameter contains the time of the response to the SIP Request which conveys 
the SDP answer. 


SDP Media 
Components 


Om 


This is a grouped field comprising several sub-fields associated with one media 
component. Since several media components may exist for a session in parallel these 
sub-fields may occur several times. 


SDP Media 
Name 


Om 


This field holds the name of the media as available in the SDP data. 


SDP Media 
Description 


Om 


This field holds the attributes of the media as available in the SDP data. 


Access 
Correlation ID 


Oc 


This parameter holds the charging identifier from the access network, consisting of 

either GPRS charging ID (GCID) which is generated by the GGSN for a GPRS PDP 

context or the Access Network Charging Identifier Value which is generated by 

another type of access network. 

It is present only if received from the access network when PCC architecture is 

implemented. 


Media Initiator 
Flag 


Oc 


This field indicates if the called party has requested the session modification and it is 
present only if the initiator was the called party. 


List of SDP Media 
Components 


Oc 


This is a grouped field which may occur several times in one CDR. The first 
occurrence describes the initial SIP session negotiation whilst the other would stem 
from session re-negotiations. 

The field is present only in a SIP session related case. 


SDP Session 
Description 


Oc 


Holds the Session portion of the SDP data exchanged between the User Agents if 
available in the SIP transaction. 


SIP Request 
Timestamp 


Om 


This parameter contains the time of the SIP Request (usually a (Re)lnvite). 


SIP Response 
Timestamp 


Om 


This parameter contains the time of the response to the SIP Request (usually a 200 
OK). 


SDP Media 
Components 


Om 


This is a grouped field comprising several sub-fields associated with one media 
component. Since several media components may exist for a session in parallel these 
sub-fields may occur several times. 


SDP Media 
Name 


Om 


This field holds the name of the media as available in the SDP data. 


SDP Media 
Description 


Om 


This field holds the attributes of the media as available in the SDP data. 


Access 
Correlation ID 


Oc 


This parameter holds the charging identifier from the access network, consisting of 

either GPRS charging ID (GCID) which is generated by the GGSN for a GPRS PDP 

context or the Access Network Charging Identifier Value which is generated by 

another type of access network. 

It is present only if received from the access network when PCC architecture is 

implemented. 


Media Initiator 
Flag 


Oc 


This field indicates if the called party has requested the session modification and it is 
present only if the initiator was the called party. 


GGSN Address 


Oc 


This parameter holds the control plane IP address of the GGSN that handles one or 
more media component(s) of an IMS session. 


Service Reason 
Return Code 


Om 


This parameter provides the returned SIP status code for the service request for the 
successful and failure case. 
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Field 


Category 


Description 


List of IVIessage 
Bodies 


Oc 


This grouped field comprising several sub-fields describing the data that may be 
conveyed end-to-end in the body of a SIP message. Since several message bodies 
may be exchanged via SIP-signalling, this grouped field may occur several times. 


Content-Type 


Om 


This sub-field of Message Bodies holds the MIME type of the message body, 
Examples are: application/zip, image/gif, audio/mpeg, etc. 


Content- 
Disposition 


Oc 


This sub-field of Message Bodies holds the content disposition of the message body 
inside the SIP signalling, Content-disposition header field equal to 'render', indicates 
that 'the body part should be displayed or otherwise rendered to the user'. Content 
disposition values are: session, render, inline, icon, alert, attachment, etc. 


Content-Length 


Om 


This sub-field of Message Bodies holds the size of the data of a message body in 
bytes. 


Originator 


Oc 


This sub-field of the "List of Message Bodies" indicates the originating party of the 
message body. 


Access Networl< 
Information 


Oc 


This field contains the content of the SIP P-header 'P-Access-Network-lnfo' if 
available. 


Service Context Id 


Om 


Holds the context information to which the CDR belongs. The information is obtained 
from the Operation Token of the Charging Data Request message. 


IIVIS Communication 
Service ID 


Oc 


This field contains the IMS communication service identifier if received In the P- 
Asserted-Service header in the SIP request. 


Record Extensions 


Oc 


A set of operator/manufacturer specific extensions to the record, conditioned upon 
existence of an extension. 
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6.1 .3.4 P-CSCF CDR Content 

The detailed description of the field is provided in TS 32.298 [51]. 



Table 6.1.3.4: Charging Data of P-CSCF CDR 



Field 


Category 


Description 


Record Type 


M 


Identifies the type of record. The parameter is derived from the Node functionality 
parameter. 


Retransmission 


Oc 


This parameter, when present, indicates that information from retransmitted Charging 
Data Requests has been used in this CDR. 


SIP Method 


Oc 


Specifies the SIP-method for which the CDR is generated. Only available in session 
unrelated cases. 


Event 


Oc 


This field identifies the SIP event package to which the SIP request is referred. 


Expires Information 


Oc 


This field indicates the validity time of either the SIP message or its content, depending 
on the SIP method. 


Role of Node 


Om 


This fields indicates the role of the P-CSCF. 


Node Address 


Om 


This item holds the address of the node providing the information for the CDR. This 
may either be the IP address or the FODN of the IMS node generating the accounting 
data. 


Session ID 


Om 


The Session identification. For a SIP session the Session-ID contains the SIP Call ID 
as defined in the Session Initiation Protocol RFC 3261 [404]. 


List Of Calling Party 
Address 


Om 


The address (Public User ID or Public Service ID) of the party requesting a service or 

initiating a session. 

Note: For P-CSCF, only one address is present 


List of Associated 
URI 


Oc 


The list of non-barred public user identities (SIP URIs and/or TEL URIs) associated to 
the public user identity under registration. 


Called Party 
Address 


Om 


In the context of an end-to-end SIP transaction this field holds the address of the party 
(Public User ID) to whom the SIP transaction is posted. 


Served Party IP 
Address 


Om 


This field contains the IP address of either the calling or called party, depending on 
whether the P-CSCF is in touch with the calling or called network. 


List of Subscription 
Id 


Om 


Holds the public user identities of the served user. 


Service Request 
Time Stamp 


Om 


This field contains the time stamp, which indicates the time at which the service was 
requested. 


Service Delivery 
Start Time Stamp 


Om 


This field holds the time stamp reflecting either: successful session set-up, a delivery 
unrelated service, an unsuccessful session set-up and an unsuccessful session 
unrelated request. 


Service Delivery 
End Time Stamp 


Oc 


This field records the time at which the service delivery was terminated. It is Present 
only in SIP session related case. Present with Charging Data Request [Stop]. 


Record Opening 
Time 


Oc 


A time stamp reflecting the time the CDF opened this record. Present only in SIP 
session related case. 


Record Closure 
Time 


Om 


A Time stamp reflecting the time the CDF closed the record. 


Inter Operator 
Identifiers 


Oc 


Holds the identification of the home network (originating and terminating) if exchanged 
via SIP signalling, as recorded in the P-Charging-Vector header. 


Originating 101 


Oc 


This parameter corresponds to Orig-IOI header of the P-Charging-Vector defined in TS 
24.229 [204]. 


Terminating 101 


Oc 


This parameter corresponds to Term-IOI header of the P-Charging-Vector defined in 
TS 24.229 [204]. 


Local Record 
Sequence Number 


Om 


This field includes a unique record number created by this node. The number is 
allocated sequentially for each partial CDR (or whole CDR) including all CDR types. 
The number is unique within the CDF. 


Record Sequence 
Number 


Oc 


This field contains a running sequence number employed to link the partial records 
generated by the CDF for a particular session. 


Cause For Record 
Closing 


Om 


This field contains a reason for the close of the CDR. 


Incomplete CDR 
Indication 


Oc 


This field provides additional diagnostics when the CDF detects missing Charging Data 
Requests. 


IMS Charging 
Identifier 


Om 


This parameter holds the IMS charging identifier (ICID) as generated by the IMS node 
for the SIP session. 
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Field 


Category 


Description 


List of Early SDP 
Media Components 


Oc 


This is a grouped field which may occur several times in one CDR. 

Each occurrence shall describe a change in the state (inactive/active or vice versa) of 

the media components negotiated during the SIP session establishment previously to 

the reception of a SIP final response to the initial SIP Invite. 

This field shall not be present if no media components are set to active before the final 

SIP session answer to the initial SIP Invite is received. 

This field can be present in either session or event CDRs. 


SDP Session 
Description 


Oc 


Holds the Session portion of SDP data exchanged in the above mentioned scenario, if 
available. 


SDP Offer 
Timestamp 


Om 


This parameter contains the time of the SIP Request which conveys the SDP offer. 


SDP Answer 
Timestamp 


Om 


This parameter contains the time of the response to the SIP Request which conveys 
the SDP answer. 


SDP IVIedia 
Components 


Om 


This is a grouped field comprising several sub-fields associated with one media 
component. Since several media components may exist for a session in parallel these 
sub-fields may occur several times. 


SDP Media 
Name 


Om 


This field holds the name of the media as available in the SDP data. 


SDP Media 
Description 


Om 


This field holds the attributes of the media as available in the SDP data. 


Access 
Correlation ID 


Oc 


This parameter holds the charging identifier from the access network, consisting of 

either GPRS charging ID (GCID) which is generated by the GGSN for a GPRS PDP 

context or the Access Network Charging Identifier Value which is generated by another 

type of access network. 

It is present only if received from the access network when PCC architecture is 

implemented. 


Media Initiator 
Flag 


Oc 


This field indicates if the called party has requested the session modification and it is 
present only if the initiator was the called party. 


List of SDP Media 
Components 


Oc 


This is a grouped field which may occur several times in one CDR. The first occurrence 
describes the initial session negotiation whilst the other would stem from session re- 
negotiations. 

The field is present only in a SIP session related case. 


SDP Session 
Description 


Oc 


Holds the Session portion of the SDP data exchanged between the User Agents if 
available in the SIP transaction. 


SIP Request 
Timestamp 


Om 


This parameter contains the time of the SIP Request (usually a (Re)lnvite). This 
parameter corresponds to SIP Request Timestamp in Charging Data Request [Interim]. 


SIP Response 
Timestamp 


Om 


This parameter contains the time of the response to the SIP Request (usually a 200 
OK). This parameter corresponds to SIP Response Timestamp in Charging Data 
Request [Interim]. 


SDP Media 
Components 


Om 


This is a grouped field comprising several sub-fields associated with one media 
component. Since several media components may exist for a session in parallel these 
sub-fields may occur several times. 


SDP Media 
Name 


Om 


This field holds the name of the media as available in the SDP data. This parameter 
corresponds to SDP-Media-Name. 


SDP Media 
Description 


Om 


This field holds the attributes of the media as available in the SDP data. This parameter 
corresponds to SDP-Media-Description. 


Access 
Correlation ID 


Oc 


This parameter holds the charging identifier from the access network, consisting of 

either GPRS charging ID (GCID) which is generated by the GGSN for a GPRS PDP 

context or the Access Network Charging Identifier Value which is generated by another 

type of access network. 

It is present only if received from the access network when PCC architecture is 

implemented. 


Authorised 
QoS 


Oc 


Authorised QoS as defined in TS 23.207 [7] / TS 29.207 [8] and applied via the Go 
interface. 


Media Initiator 
Flag 


Oc 


This field indicates if the called party has requested the session modification and it is 
present only if the initiator was the called party. 


GGSN Address 


Oc 


This parameter holds the control plane IP address of the GGSN that handles one or 
more media component(s) of a IMS session. 


Service Reason 
Return Code 


Om 


This parameter provides the returned SIP status code for the service request for the 
successful and failure case. 


List of Message 
Bodies 


Oc 


This grouped field comprising several sub-fields describing the data that may be 
conveyed end-to-end in the body of a SIP message. Since several message bodies 
may be exchanged via SIP-signalling, this grouped field may occur several times. 


Content-Type 


Om 


This sub-field of Message Bodies holds the MIME type of the message body. Examples 
are: application/zip, image/gif, audio/mpeg, etc. 
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Field 


Category 


Description 


Content- 
Disposition 


Oc 


This sub-field of IVIessage Bodies holds the content disposition of the message body 
inside the SIP signalling, Content-disposition header field equal to 'render', indicates 
that 'the body part should be displayed or otherwise rendered to the user'. Content 
disposition values are; session, render, inline, icon, alert, attachment, etc. 


Content-Length 


Om 


This sub-field of Message Bodies holds the size of the data of a message body in 
bytes. 


Originator 


Oc 


This sub-field of the "List of Message Bodies" indicates the originating party of the 
message body. 


Access Networl< 
Information 


Oc 


This field contains the content of the SIP P-header 'P-Access-Network-lnfo' if available. 


Service Context Id 


Om 


Holds the context information to which the CDR belongs. The information is obtained 
from the Operation Token of the Charging Data Request message. 


Record Extensions 


Oc 


A set of operator/manufacturer specific extensions to the record, conditioned upon 
existence of an extension. 
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6.1.3.5 l-CSCF CDR Content 

The detailed description of the field is provided in TS 32.298 [51]. 



Table 6.1.3.5: Charging Data of l-CSCF CDR 



Field 


Category 


Description 


Record Type 


M 


Identifies the type of record. The parameter is derived from the Node functionality 
parameter. 


Retransmission 


Oc 


This parameter, when present, indicates that information from retransmitted Charging 
Data Requests has been used in this CDR 


SIP Method 


Oc 


Specifies the SIP-method for which the CDR is generated. Only available in session 
unrelated cases. 


Event 


Oc 


This field identifies the SIP event package to which the SIP request is referred. 


Expires Information 


Oc 


This field indicates the validity time of either the SIP message or its content, 
depending on the SIP method. 


Role of Node 


Om 


This fields indicates the role of the l-CSCF. 


Node Address 


Om 


This item holds the address of the node providing the information for the CDR. This 
may either be the IP address or the FODN of the IMS node generating the accounting 
data. 


Session ID 


Om 


The Session identification. For a SIP session the Session-ID contains the SIP Call ID 
as defined in the Session Initiation Protocol RFC 3261 [404]. 


List Of Calling Party 
Address 


Om 


The address or addresses (Public User ID or Public Service ID) of the party 
requesting a service or initiating a session. 


List of Associated 
URI 


Oc 


The list of non-barred public user identities (SIP URIs and/or TEL URIs) associated to 
the public user identity under registration. 


Called Party Address 


Om 


In the context of an end-to-end SIP transaction this field holds the address of the party 
(Public User ID) to whom the SIP transaction is posted. 


Service Request 
Time Stamp 


Om 


This field contains the time stamp, which indicates the time at which the service was 
requested. This parameter corresponds to SIP Request Timestamp. Present with 
Charging Data Request [Event]. 


Inter Operator 
Identifiers 


Oc 


Holds the identification of the home network (originating and terminating) if exchanged 
via SIP signalling, as recorded in the P-Charging-Vector header. 


Originating 101 


Oc 


This parameter corresponds to Orig-IOI header of the P-Charging-Vector defined in 
TS 24.229 [204]. 


Terminating 101 


Oc 


This parameter corresponds to Term-IOI header of the P-Charging-Vector defined in 
TS 24.229 [204]. 


Local Record 
Sequence Number 


Om 


This field includes a unique record number created by this node. The number is 
allocated sequentially for each partial CDR (or whole CDR) including all CDR types. 
The number is unique within the CDF. 


Cause For Record 
Closing 


Om 


This field contains a reason for the close of the CDR. 


Incomplete CDR 
Indication 


Oc 


This field provides additional diagnostics when the CDF detects missing Charging 
Data Requests. 


S-CSCF Information 


Oc 


This field contains Information related to the serving CSCF, e.g. the S-CSCF 
capabilities upon registration event or the S-CSCF address upon the session 
establishment event. 


IMS Charging 
Identifier 


Om 


This parameter holds the IMS charging identifier (ICID) as generated by the IMS node 
for the SIP session. 


Service Reason 
Return Code 


Om 


This parameter provides the returned SIP status code for the service request for the 
successful and failure case. 


Access Network 
Information 


Oc 


This field contains the content of the SIP P-header 'P-Access-Network-lnfo' if 
available. 


Service Context Id 


Om 


Holds the context information to which the CDR belongs. The information is obtained 
from the Operation Token of the Charging Data Request message. 


Record Extensions 


Oc 


A set of operator/manufacturer specific extensions to the record, conditioned upon 
existence of an extension. 



£75/ 



3GPP TS 32.260 version 7.7.0 Release 7 



61 



ETSI TS 132 260 V7.7.0 (2010-04) 



6.1.3.6 M RFC CD R Content 

The detailed description of the field is provided in TS 32.298 [51]. 



Table 6.1.3.6: Charging Data of MRFC CDR 



Field 


Category 


Description 


Record Type 


M 


Identifies the type of record. The parameter is derived from the Node functionality 
parameter. 


Retransmission 


Oc 


This parameter, when present, indicates that information from retransmitted 
Charging Data Requests has been used in this CDR. 


SIP Method 


Oc 


Specifies the SIP-method for which the CDR is generated. Only available in 
session unrelated cases. 


Event 


Oc 


This field identifies the SIP event package to which the SIP request is referred. 


Expires Information 


Oc 


This field indicates the validity time of either the SIP message or its content, 
depending on the SIP method. 


Role of Node 


Om 


This field indicates the role of the MRFC. 


Node Address 


Om 


This item holds the address of the node providing the information for the CDR. 
This may either be the IP address or the FODN of the IMS node generating the 
accounting data. 


Session ID 


Om 


The Session identification. For a SIP session the Session-ID contains the SIP Call 
ID as defined in the Session Initiation Protocol RFC 3261 [404]. 


Service ID 


Om 


This field identifies the service the MRFC is hosting. For conferences the 
conference ID is used here. 


List Of Calling Party 
Address 


Om 


The address or addresses (Public User ID or Public Service ID) of the party 
requesting a service or initiating a session. 


Called Party Address 


Oc 


For SIP transactions, except for registration, this field holds the address of the 
party (Public User ID or Public Service ID) to whom the SIP transaction is posted. 
For registration transactions, this field holds the Public User ID under registration. 


Requested Party 
Address 


Oc 


For SIP transactions this field holds the address of the party (Public User ID or 

Public Service ID) to whom the SIP transaction was originally posted. 

This field is only present if different from the Called Party Address parameter. 


List of Called Asserted 
Identity 


Oc 


The address or addresses of the final asserted identities. Present if the final 
asserted identities are available in the SIP 2xx response. 


List of Subscription Id 


Om 


Holds the public user identities of the served user 


Service Request Time 
Stamp 


Om 


This field contains the time stamp which indicates the time at which the service 
was requested. This parameter corresponds to SIP Request Timestamp. Present 
with Charging Data Request [Start] and Charging Data Request [Event]. 


Service Delivery Start 
Time Stamp 


Om 


This field holds the time stamp reflecting either: successful session set-up, a 
delivery unrelated service, an unsuccessful session set-up and an unsuccessful 
session unrelated request. This parameter corresponds to SIP Response 
Timestamp. Present with Charging Data Request [Start] and Charging Data 
Request [EVENT]. 


Service Delivery End 
Time Stamp 


Oc 


This field records the time at which the service delivery was terminated. It is 
Present only in SIP session related case. This parameter corresponds to SIP 
Request Timestamp. Present with Charging Data Request [Stop]. 


Record Opening Time 


Oc 


A time stamp reflecting the time the CDF opened this record. Present only in SIP 
session related case. 


Record Closure Time 


Om 


A Time stamp reflecting the time the CDF closed the record. 


Application Servers 
Information 


Oc 


This is a grouped CDR field containing the fields: 'Application Server Involved' and 
'Application Provided Called Parties'. 


Application Servers 
Involved 


Oc 


Holds the ASs (if any) identified by the SIP URIs. 


Application 
Provided Called Parties 


Oc 


Holds a list of the Called Party Address(es), if the address(es) are determined by 
anAS(SIPURI, E.164...). 


Inter Operator 
Identifiers 


Oc 


Holds the identification of the home network (originating and terminating) if 
exchanged via SIP signalling, as recorded in the P-Charging-Vector header. 


Originating 101 


Oc 


This parameter corresponds to Orig-IOI header of the P-Charging-Vector defined 
in TS 24.229 [204]. 


Terminating 101 


Oc 


This parameter corresponds to Term-IOI header of the P-Charging-Vector defined 
in TS 24.229 [204]. 


Local Record 
Sequence Number 


Om 


This field includes a unique record number created by this node. The number is 
allocated sequentially for each partial CDR (or whole CDR) including all CDR 
types. The number is unique within the CDF. 


Record Sequence 
Number 


Oc 


This field contains a running sequence number employed to link the partial records 
generated by the CDF for a particular session. 
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Field 


Category 


Description 


Cause For Record 
Closing 


Om 


This field contains a reason for the close of the CDR. 


Incomplete CDR 
Indication 


Oc 


This field provides additional diagnostics when the CDF detects missing Charging 
Data Requests. 


IMS Charging Identifier 


Om 


This parameter holds the IMS charging identifier (ICID) as generated by the IMS 
node for the SIP session. 


List of Early SDP Media 
Components 


Oc 


This is a grouped field which may occur several times in one CDR. 

Each occurrence shall describe a change in the state (inactive/active or vice 

versa) of the media components negotiated during the SIP session establishment 

previously to the reception of a SIP final response to the initial SIP Invite. 

This field shall not be present if no media components are set to active before the 

final SIP session answer to the initial SIP Invite is received. 

This field can be present in either session or event CDRs. 


SDP Session 
Description 


Oc 


Holds the Session portion of SDP data exchanged in the above mentioned 
scenario, if available. 


SDP Offer 
Timestamp 


Om 


This parameter contains the time of the SIP Request which conveys the SDP 
offer. 


SDP Answer 
Timestamp 


Om 


This parameter contains the time of the response to the SIP Request which 
conveys the SDP answer. 


SDP Media 
Components 


Om 


This is a grouped field comprising several sub-fields associated with one media 
component. Since several media components may exist for a session in parallel 
these sub-fields may occur several times. 


SDP Media 
Name 


Om 


This field holds the name of the media as available in the SDP data. 


SDP Media 
Description 


Om 


This field holds the attributes of the media as available in the SDP data. 


Access 
Correlation ID 


Oc 


This parameter holds the charging identifier from the access network, consisting of 

either GPRS charging ID (GCID) which is generated by the GGSN for a GPRS 

PDP context or the Access Network Charging Identifier Value which is generated 

by another type of access network. 

It is present only if received from the access network when PCC architecture is 

implemented. 


Media Initiator Flag 


Oc 


This field indicates if the called party has requested the session modification and it 
is present only if the initiator was the called party. 


List of SDP Media 
Components 


Oc 


This is a grouped field which may occur several times in one CDR. The first 
occurrence describes the initial session negotiation whilst the other would stem 
from session re-negotiations. 
The field is present only in a SIP session related case 


SDP Session 
Description 


Oc 


Holds the Session portion of the SDP data exchanged between the User Agents if 
available in the SIP transaction. 


SIP Request 
Timestamp 


Om 


This parameter contains the time of the SIP Request (usually a (Re)lnvite). This 
parameter corresponds to SIP Request Timestamp in the Charging Data Request 
[Interim]. 


SIP Response 
Timestamp 


Om 


This parameter contains the time of the response to the SIP Request (usually a 
200 OK). This parameter corresponds to SIP Response Timestamp In the 
Charging Data Request [Interim]. 


SDP Media 
Components 


Om 


This is a grouped field comprising several sub-fields associated with one media 
component. Since several media components may exist for a session in parallel 
these sub-fields may occur several times. 


SDP Media 
Name 


Om 


This field holds the name of the media as available in the SDP data. This 
parameter corresponds to SDP-Media-Name. 


SDP Media 
Description 


Om 


This field holds the attributes of the media as available in the SDP data. 


Access 
Correlation ID 


Oc 


This parameter holds the charging identifier from the access network, consisting of 

either GPRS charging ID (GCID) which is generated by the GGSN for a GPRS 

PDP context or the Access Network Charging Identifier Value which is generated 

by another type of access network. 

It is present only if received from the access network when PCC architecture is 

implemented. 


Media Initiator Flag 


Oc 


This field indicates if the called party has requested the session modification and it 
is present only if the initiator was the called party. 


GGSN Address 


Oc 


This parameter holds the control plane IP address of the GGSN that handles one 
or more media component(s) of a IMS session. 


Service Reason Return 
Code 


Om 


This parameter provides the returned SIP status code for the service request for 
the successful and failure case, 
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Field 


Category 


Description 


Access Network 
Information 


Oc 


This field contains the content of the SIP P-header 'P-Access-Network-lnfo' if 
available. 


Service Context Id 


Om 


Holds the context information to which the CDR belongs. The information is 
obtained from the Operation Token of the Charging Data Request message. 


Record Extensions 


Oc 


A set of operator/manufacturer specific extensions to the record, conditioned upon 
existence of an extension. 
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6.1.3.7 MGCF CD R Content 

The detailed description of the field is provided in TS 32.298 [51]. 



Table 6.1.3.7: Charging Data of MGCF CDR 



Field 


Category 


Description 


Record Type 


M 


Identifies the type of record. The parameter is derived from the Node 
functionality parameter. 


Retransmission 


Oc 


This parameter, when present, indicates that information from retransmitted 
Charging Data Requests has been used in this CDR 


SIP Method 


Oc 


Specifies the SIP-method for which the CDR is generated. Only available in 
session unrelated cases. 


Event 


Oc 


This field identifies the SIP event package to which the SIP request is referred. 


Expires Information 


Oc 


This field indicates the validity time of either the SIP message or its content, 
depending on the SIP method. 


Role of Node 


Om 


This field indicates the role of the MGCF. 


Node Address 


Om 


This item holds the address of the node providing the information for the CDR. 
This may either be the IP address or the FODN of the IMS node generating the 
accounting data. 


Session ID 


Om 


The Session identification. For a SIP session the Session-ID contains the SIP 
Call ID as defined in the Session Initiation Protocol RFC 3261 [404]. 


List Of Calling Party 
Address 


Om 


The address or addresses (Public User ID or Public Service ID) of the party 
requesting a service or initiating a session. 


Called Party Address 


Om 


In the context of an end-to-end SIP transaction this field holds the address of the 
party (Public User ID) to whom the SIP transaction is posted. 


Service Request Time 
Stamp 


Om 


This field contains the time stamp which indicates the time at which the service 
was requested. This parameter corresponds to SIP Request Timestamp. Present 
with Charging Data Request [Start] and Charging Data Request [Event]. 


Service Delivery Start 
Time Stamp 


Om 


This field holds the time stamp reflecting either: successful session set-up, a 
delivery unrelated service, an unsuccessful session set-up and an unsuccessful 
session unrelated request. This parameter corresponds to SIP Response 
Timestamp. Present with Charging Data Request [Start] and Charging Data 
Request [Event]. 


Service Delivery End 
Time Stamp 


Oc 


This field records the time at which the service delivery was terminated. It is 
Present only in SIP session related case. This parameter corresponds to SIP 
Request Timestamp. Present with Charging Data Request [Stop]. 


Record Opening Time 


Oc 


A time stamp reflecting the time the CDF opened this record. Present only in SIP 
session related case. 


Record Closure Time 


Om 


A Time stamp reflecting the time the CDF closed the record. 


Inter Operator Identifiers 


Oc 


Holds the identification of the home network (originating and terminating) if 
exchanged via SIP signalling, as recorded in the P-Charging-Vector header. 


Originating 101 


Oc 


This parameter corresponds to Orig-IOI header of the P-Charging-Vector defined 
in TS 24.229 [204]. 


Terminating 101 


Oc 


This parameter corresponds to Term-IOI header of the P-Charging-Vector 
defined in TS 24.229 [204]. 


Local Record Sequence 
Number 


Om 


This field includes a unique record number created by this node. The number is 
allocated sequentially for each partial CDR (or whole CDR) including all CDR 
types. The number is unique within the CDF. 


Record Sequence 
Number 


Oc 


This field contains a running sequence number employed to link the partial 
records generated by the CDF for a particular session. 


Cause For Record 
Closing 


Om 


This field contains a reason for the close of the CDR. 


Incomplete CDR 
Indication 


Oc 


This field provides additional diagnostics when the CDF detects missing 
Charging Data Requests. 


IMS Charging Identifier 


Om 


This parameter holds the IMS charging identifier (ICID) as generated by the IMS 
node for the SIP session. 


List of Early SDP Media 
Components 


Oc 


This is a grouped field which may occur several times in one CDR. 

Each occurrence shall describe a change in the state (inactive/active or vice 

versa) of the media components negotiated during the SIP session 

establishment previously to the reception of a SIP final response to the initial SIP 

Invite. 

This field shall not be present if no media components are set to active before 

the final SIP session answer to the initial SIP Invite is received. 

This field can be present in either session or event CDRs. 
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Field 


Category 


Description 


SDP Session 
Description 


Oc 


Holds the Session portion of SDP data exchanged in the above mentioned 
scenario, if available. 


SDP Offer Timestamp 


Om 


This parameter contains the time of the SIP Request which conveys the SDP 
offer. 


SDP Answer 
Timestamp 


Om 


This parameter contains the time of the response to the SIP Request which 
conveys the SDP answer. 


SDP IVIedia 
Components 


Om 


This is a grouped field comprising several sub-fields associated with one media 
component. Since several media components may exist for a session in parallel 
these sub-fields may occur several times. 


SDP Media Name 


Om 


This field holds the name of the media as available in the SDP data. 


SDP Media 
Description 


Om 


This field holds the attributes of the media as available in the SDP data. 


Media Initiator Flag 


Oc 


This field indicates if the called party has requested the session modification and 
it is present only if the initiator was the called party. 


List of SDP Media 
Components 


Oc 


This is a grouped field which may occur several times in one CDR. The first 
occurrence describes the initial session negotiation whilst the other would stem 
from session re-negotiations. 
The field is present only in a SIP session related case. 


SDP Session 
Description 


Oc 


Holds the Session portion of the SDP data exchanged between the User Agents 
if available in the SIP transaction. 


SIP Request 
Timestamp 


Om 


This parameter contains the time of the SIP Request (usually a (Re)lnvite). This 
parameter corresponds to SIP Request Timestamp in Charging Data Request 
[Interim]. 


SIP Response 
Timestamp 


Om 


This parameter contains the time of the response to the SIP Request (usually a 
200 OK). This parameter corresponds to SIP Response Timestamp in Charging 
Data Request [Interim]. 


SDP Media 
Components 


Om 


This is a grouped field comprising several sub-fields associated with one media 
component. Since several media components may exist for a session in parallel 
these sub-fields may occur several times. 


SDP Media Name 


Om 


This field holds the name of the media as available in the SDP data. This 
parameter corresponds to SDP-Media-Name. 


SDP Media 
Description 


Om 


This field holds the attributes of the media as available in the SDP data. 


Media Initiator Flag 


Oc 


This field indicates if the called party has requested the session modification and 
it is present only if the initiator was the called party. 


Service Reason Return 
Code 


Om 


This parameter provides the returned SIP status code for the service request for 
the successful and failure case. 


Trunk Group ID 
Incoming/Outgoing 


Om 


Contains the outgoing trunk group ID for an outgoing session/call or the incoming 
trunk group ID for an incoming session/call. 


Bearer Service 


Om 


Holds the used bearer service for the PSTN leg. 


Access Network 
Information 


Oc 


This field contains the content of the SIP P-header 'P-Access-Network-lnfo' if 
available. 


Service Context Id 


Om 


Holds the context information to which the CDR belongs. The information is 
obtained from the Operation Token of the Charging Data Request message. 


Record Extensions 


Oc 


A set of operator/manufacturer specific extensions to the record, conditioned 
upon existence of an extension. 
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6.1.3.8 BGCF CDR Content 

The detailed description of the field is provided in TS 32.298 [51]. 



Table 6.1.3.8: Charging Data of BGCF CDR 



Field 


Category 


Description 


Record Type 


M 


Identifies the type of record. The parameter is derived from the Node functionality 
parameter. 


Retransmission 


Oc 


This parameter, when present, indicates that information from retransmitted 
Charging Data Requests has been used in this CDR. 


SIP Method 


Oc 


Specifies the SIP-method for which the CDR is generated. Only available in 
session unrelated cases. 


Event 


Oc 


This field identifies the SIP event package to which the SIP request is referred. 


Expires Information 


Oc 


This field indicates the validity time of either the SIP message or its content, 
depending on the SIP method. 


Role of Node 


Om 


This field indicates the role of the BGCF. 


Node Address 


Om 


This item holds the address of the node providing the information for the CDR. 
This may either be the IP address or the FODN of the IMS node generating the 
accounting data. 


Session ID 


Om 


The Session identification. For a SIP session the Session-ID contains the SIP 
Call ID as defined in the Session Initiation Protocol RFC 3261 [404]. 


List Of Calling Party 
Address 


Om 


The address or addresses (Public User ID or Public Service ID) of the party 
requesting a service or initiating a session. 


Called Party Address 


Om 


In the context of an end-to-end SIP transaction this field holds the address of the 
party (Public User ID) to whom the SIP transaction is posted. 


Service Request Time 
Stamp 


Om 


This field contains the time stamp which indicates the time at which the service 
was requested. This parameter corresponds to SIP Request Timestamp. Present 
with Charging Data Request [Start] and Charging Data Request [Event]. 


Service Delivery Start 
Time Stamp 


Om 


This field holds the time stamp reflecting either: successful session set-up, a 
delivery unrelated service, an unsuccessful session set-up and an unsuccessful 
session unrelated request. This parameter corresponds to SIP Response 
Timestamp. Present with Charging Data Request [Start] and Charging Data 
Request [Event]. 


Service Delivery End 
Time Stamp 


Oc 


This field records the time at which the service delivery was terminated. It is 
Present only in SIP session related case. This parameter corresponds to SIP 
Request Timestamp. Present with Charging Data Request [Stop]. 


Record Opening Time 


Oc 


A time stamp reflecting the time the CDF opened this record. Present only in SIP 
session related case. 


Record Closure Time 


Om 


A Time stamp reflecting the time the CDF closed the record 


Inter Operator Identifiers 


Oc 


Holds the identification of the home network (originating and terminating) if 
exchanged via SIP signalling, as recorded in the P-Charging-Vector header. 


Originating 101 


Oc 


This parameter corresponds to Orig-IOI header of the P-Charging-Vector defined 
in TS 24.229 [204]. 


Terminating 101 


Oc 


This parameter corresponds to Term-IOI header of the P-Charging-Vector 
defined in TS 24.229 [204]. 


Local Record Sequence 
Number 


Om 


This field includes a unique record number created by this node. The number is 
allocated sequentially for each partial CDR (or whole CDR) including all CDR 
types. The number is unique within the CDF. 


Record Sequence 
Number 


Oc 


This field contains a running sequence number employed to link the partial 
records generated by the CDF for a particular session. 


Cause For Record 
Closing 


Om 


This field contains a reason for the close of the CDR. 


Incomplete CDR 
Indication 


Oc 


This field provides additional diagnostics when the CDF detects missing Charging 
Data Requests. 


IMS Charging Identifier 


Om 


This parameter holds the IMS charging identifier (ICID) as generated by the IMS 
node for the SIP session. 


List of Early SDP Media 
Components 


Oc 


This is a grouped field which may occur several times in one CDR. 

Each occurrence shall describe a change in the state (inactive/active or vice 

versa) of the media components negotiated during the SIP session establishment 

previously to the reception of a SIP final response to the initial SIP Invite. 

This field shall not be present if no media components are set to active before the 

final SIP session answer to the initial SIP Invite is received. 

This field can be present in either session or event CDRs. 


SDP Session 
Description 


Oc 


Holds the Session portion of SDP data exchanged in the above mentioned 
scenario, if available. 
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Field 


Category 


Description 


SDP Offer Timestamp 


Om 


This parameter contains the time of the SIP Request which conveys the SDP 
offer. 


SDR Answer 
Timestamp 


Om 


This parameter contains the time of the response to the SIP Request which 
conveys the SDP answer. 


SDP Media 
Components 


Om 


This is a grouped field comprising several sub-fields associated with one media 
component. Since several media components may exist for a session in parallel 
these sub-fields may occur several times. 


SDP Media Name 


Om 


This field holds the name of the media as available in the SDP data. 


SDP Media 
Description 


Om 


This field holds the attributes of the media as available in the SDP data. 


Media Initiator Flag 


Oc 


This field indicates if the called party has requested the session modification and 
it is present only if the initiator was the called party. 


List of SDP Media 
Components 


Oc 


This is a grouped field which may occur several times in one CDR. The first 
occurrence describes the initial session negotiation whilst the other would stem 
from session re-negotiations. 
The field is present only in a SIP session related case. 


SDP Session 
Description 


Oc 


Holds the Session portion of the SDP data exchanged between the User Agents 
if available in the SIP transaction. 


SIP Request 
Timestamp 


Om 


This parameter contains the time of the SIP Request (usually a (Re)lnvite). This 
parameter corresponds to SIP Request Timestamp in Charging Data Request 
[Interim]. 


SIP Response 
Timestamp 


Om 


This parameter contains the time of the response to the SIP Request (usually a 
200 OK). This parameter corresponds to SIP Response Timestamp in Charging 
Data Request [Interim]. 


SDP Media 
Components 


Om 


This is a grouped field comprising several sub-fields associated with one media 
component. Since several media components may exist for a session in parallel 
these sub-fields may occur several times. 


SDP Media Name 


Om 


This field holds the name of the media as available in the SDP data. 


SDP Media 
Description 


Om 


This field holds the attributes of the media as available in the SDP data. 


Media Initiator Flag 


Oc 


This field indicates if the called party has requested the session modification and 
it is present only if the initiator was the called party. 


Service Reason Return 
Code 


Om 


This parameter provides the returned SIP status code for the service request for 
the successful and failure case, 


Access Network 
Information 


Oc 


This field contains the content of the SIP P-header 'P-Access-Network-lnfo' if 
available. 


Service Context Id 


Om 


Holds the context information to which the CDR belongs. The information is 
obtained from the Operation Token of the Charging Data Request message. 


Record Extensions 


Oc 


A set of operator/manufacturer specific extensions to the record, conditioned 
upon existence of an extension. 
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6.1.3.9 SIP AS CDR Content 

The detailed description of the field is provided in TS 32.298 [51]. 



Table 6.1.3.9: Charging Data of AS CDR 



Field 


Category 


Description 


Record Type 


M 


Identifies the type of record. The parameter is derived from the Node 
functionality parameter. 


Retransmission 


Oc 


This parameter, when present, indicates that information from 
retransmitted Charging Data Requests has been used in this CDR 


SIP Method 


Oc 


Specifies the SIP-method for which the CDR is generated. Only 
available in session unrelated cases. 


Event 


Oc 


This field identifies the SIP event package to which the SIP request is 
referred. 


Expires Information 


Oc 


This field indicates the validity time of either the SIP message or its 
content, depending on the SIP method. 


Role of Node 


Om 


This fields indicates the role of the AS. 


Node Address 


Om 


This item holds the address of the node providing the information for 
the CDR. This may either be the IP address or the FODN of the IMS 
node generating the accounting data. 


Session ID 


Om 


The Session identification. For a SIP session the Session-ID contains 
the SIP Call ID as defined in the Session Initiation Protocol RFC 
3261 [404]. 


List Of Calling Party Address 


Om 


The address or addresses (Public User ID or Public Service ID) of 
the party requesting a service or initiating a session. 


Called Party Address 


Om 


For SIP transactions, except for registration, this field holds the 

address of the party (Public User ID or Public Service ID) to whom 

the SIP transaction is posted. 

For registration transactions, this field holds the Public User ID under 

registration. 


Alternate Charged Party Address 


Oc 


The address of an alternate party that is identified by the AS at 
session initiation, and is charged in place of the calling party. 


Requested Party Address 


Oc 


For SIP transactions this field holds the address of the party (Public 

User ID or Public Service ID) to whom the SIP transaction was 

originally posted. 

This field is only present if different from the Called Party Address 

parameter. 


List of Subscription Id 


Om 


Holds the public user identities of the served user 


List of Called Asserted Identity 


Oc 


The address or addresses of the final asserted identities. Present if 
the final asserted identities are available in the SIP 2xx response. 


Service Request Time Stamp 


Om 


This field contains the time stamp which indicates the time at which 
the service was requested. This parameter corresponds to SIP 
Request Timestamp. Present with Charging Data Request [Start] and 
Charging Data Request [Event]. 


Service Delivery Start Time Stamp 


Om 


This field holds the time stamp reflecting either: successful session 
set-up, a delivery unrelated service, an unsuccessful session set-up 
and an unsuccessful session unrelated request. This parameter 
corresponds to SIP Response Timestamp. Present with Charging 
Data Request [Start] and Charging Data Request [Event]. 


Service Delivery End Time Stamp 


Oc 


This field records the time at which the service delivery was 
terminated. It is Present only in SIP session related case. This 
parameter corresponds to SIP Request Timestamp. Present with 
Charging Data Request [Stop]. 


Record Opening Time 


Oc 


A time stamp reflecting the time the CDF opened this record. Present 
only in SIP session related case. 


Record Closure Time 


Om 


A Time stamp reflecting the time the CDF closed the record. 


Inter Operator Identifiers 


Oc 


Holds the identification of the home network (originating and 
terminating) if exchanged via SIP signalling, as recorded in the P- 
Charging-Vector header. 


Originating 101 


Oc 


This parameter corresponds to Orig-IOI header of the P-Charging- 
Vector defined in TS 24.229 [204]. 


Terminating 101 


Oc 


This parameter corresponds to Term-IOI header of the P-Charging- 
Vector defined in TS 24.229 [204]. 
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Field 


Category 


Description 


Local Record Sequence Number 


Om 


This field includes a unique record number created by this node. The 
number is allocated sequentially for each partial CDR (or whole CDR) 
including all CDR types. The number is unique within the CDF. 


Record Sequence Number 


Oc 


This field contains a running sequence number employed to link the 
partial records generated by the CDF for a particular session. 


Cause For Record Closing 


Om 


This field contains a reason for the close of the CDR. 


Incomplete CDR Indication 


Oc 


This field provides additional diagnostics when the CDF detects 
missing Charging Data Requests. 


IIVIS Charging Identifier 


Om 


This parameter holds the IMS charging identifier (ICID) as generated 
by the IMS node for the SIP session. 


List of Early SDP IVIedia Components 


Oc 


This is a grouped field which may occur several times in one CDR. 

Each occurrence shall describe a change in the state (inactive/active 

or vice versa) of the media components negotiated during the SIP 

session establishment previously to the reception of a SIP final 

response to the initial SIP Invite. 

This field shall not be present if no media components are set to 

active before the final SIP session answer to the initial SIP Invite is 

received. 

This field can be present in either session or event CDRs. 


SDP Session Description 


Oc 


Holds the Session portion of SDP data exchanged in the above 
mentioned scenario, if available. 


SDP Offer Timestamp 


Om 


This parameter contains the time of the SIP Request which conveys 
the SDP offer. 


SDP Answer Timestamp 


Om 


This parameter contains the time of the response to the SIP Request 
which conveys the SDP answer. 


SDP Media Components 


Om 


This is a grouped field comprising several sub-fields associated with 
one media component. Since several media components may exist 
for a session in parallel these sub-fields may occur several times. 


SDP Media Name 


Om 


This field holds the name of the media as available in the SDP data. 


SDP Media Description 


Om 


This field holds the attributes of the media as available in the SDP 
data. 


Access Correlation ID 


Oc 


This parameter holds the charging identifier from the access network, 

consisting of either GPRS charging ID (GCID) which is generated by 

the GGSN for a GPRS PDP context or the Access Network Charging 

Identifier Value which is generated by another type of access 

network. 

It is present only if received from the access network when PCC 

architecture is implemented. 


Media Initiator Flag 


Oc 


This field indicates if the called party has requested the session 
modification and it is present only if the initiator was the called party. 


List of SDP Media Components 


Oc 


This is a grouped field which may occur several times in one CDR. 
The first occurrence describes the initial session negotiation whilst 
the other would stem from session re-negotiations. 
The field is present only in a SIP session related case. 


SDP Session Description 


Oc 


Holds the Session portion of the SDP data exchanged between the 
User Agents if available in the SIP transaction. 


SIP Request Timestamp 


Om 


This parameter contains the time of the SIP Request (usually a 
(Re)lnvite). This parameter corresponds to SIP Request Timestamp 
in Charging Data Request [Interim]. 


SIP Response Timestamp 


Om 


This parameter contains the time of the response to the SIP Request 
(usually a 200 OK). This parameter corresponds to SIP Response 
Timestamp in Charging Data Request [Interim]. 


SDP Media Components 


Om 


This is a grouped field comprising several sub-fields associated with 
one media component. Since several media components may exist 
for a session in parallel these sub-fields may occur several times. 


SDP Media Name 


Om 


This field holds the name of the media as available in the SDP data. 


SDP Media Description 


Om 


This field holds the attributes of the media as available in the SDP 
data. 


Access Correlation ID 


Oc 


This parameter holds the charging identifier from the access network, 

consisting of either GPRS charging ID (GCID) which is generated by 

the GGSN for a GPRS PDP context or the Access Network Charging 

Identifier Value which is generated by another type of access 

network. 

It is present only if received from the access network when PCC 

architecture is implemented. 
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Field 


Category 


Description 


Media Initiator Flag 


Oc 


This field indicates if the called party has requested the session 
modification and it is present only if the initiator was the called party. 


GGSN Address 


Oc 


This parameter holds the control plane IP address of the GGSN that 
handles one or more media component(s) of a IMS session. 


Service Reason Return Code 


Om 


This parameter provides the returned SIP status code for the service 
request for the successful and failure case, 


Service Specific Info 


Oc 


This is a grouped field that contains service specific data if and as 
provided by an Application Server. It may occur several times in one 
CDR. 


Service Specific Data 


Om 


This sub-field of Service Specific Data holds the value of the Service 
Specific Data. 


Service Specific Type 


Om 


This sub-field of Service Specific Data holds the type of the Service 
Specific Data. 


List of Message Bodies 


Oc 


This grouped field comprising several sub-fields describing the data 
that may be conveyed end-to-end in the body of a SIP message. 
Since several message bodies may be exchanged via SIP-signalling, 
this grouped field may occur several times. 


Content-Type 


Om 


This sub-field of Message Bodies holds the MIME type of the 
message body, Examples are: application/zip, image/gif, audio/mpeg, 
etc. 


Content-Disposition 


Oc 


This sub-field of Message Bodies holds the content disposition of the 
message body inside the SIP signalling. Content-disposition header 
field equal to 'render', indicates that 'the body part should be 
displayed or otherwise rendered to the user'. Content disposition 
values are : session, render, inline, icon, alert, attachment, etc. 


Content-Length 


Om 


This sub-field of Message Bodies holds the size of the data of a 
message body in bytes. 


Originator 


Oc 


This sub-field of the "List of Message Bodies" indicates the 
originating party of the message body. 


Access Network Information 


Oc 


This field contains the content of the SIP P-header 'P-Access- 
Network-lnfo' if available. 


Service Context Id 


Om 


Holds the context information to which the CDR belongs. The 
information is obtained from the Operation Token of the Charging 
Data Request message. 


IMS Communication Service ID 


Oc 


This field contains the IMS communication service identifier if 
received in the P-Asserted-Service header in the SIP request. 


Record Extensions 


Oc 


A set of operator/manufacturer specific extensions to the record, 
conditioned upon existence of an extension. 



6.2 Data description for IIVIS online charging 
6.2.1 Ro message contents 

The IMS nodes generate debit and reserve units information that can be transferred from the CTF to the OCF. For this 
purpose, IMS online charging utilises the Debit Units and Reserve Units procedure that is specified in the 3GPP debit 
unit operation in TS 32.299 [50]. 

The Debit and reserve units procedure employs the Debit and Reserve Units Request and Debit and Reserve Units 
Response messages. Table 6.2.1 describes the use of these messages in IMS online charging. 

Table 6.2.1 : Online Charging Messages Reference Table 



Command-Name 


Source 


Destination 


Debit and Reserve Units Request 


MRFC, AS, IMS-GWF 


OCS 


Debit and Reserve Units Response 


OCS 


MRFC, AS, IMS-GWF 
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6.2.1.1 



Debit and Reserve Units Request Message 



Table 6.2. 1 . 1 illustrates the basic structure of a Debit and Reserve Units Request message from the CTF in MRPC and 
AS and the IMS-GWF as used for IMS online charging. 

Table 6.2.1.1 : Debit and reserve units Request IVIessage Contents 



Field 


Category 


Description 


Session Identifier 


M 


Described in 32.299 [50] 


Originator Host 


M 


Described in 32.299 [50] 


Originator Domain 


M 


Described in 32.299 [50] 


Destination Domain 


M 


Described in 32.299 [50] 


Operation Identifier 


M 


Described in 32.299 [50] 


Operation Tol<en 


M 


Described in 32.299 [50] 


Operation Type 


M 


Described in 32.299 [50] 


Operation Number 


M 


Described in 32.299 [50] 


Destination Host 


Oc 


Described in 32.299 [50] 


User Name 


Oc 


Tine field contains the Private User Identity [201] 


Origination State 


Oc 


Described in 32.299 [50] 


Origination Timestamp 


Oc 


Described in 32.299 [50] 


Subscriber Identifier 


Om 


This field contains the identification of the mobile subscriber (i.e. IVISISDN or SIP- 
URI) that uses the requested service. 


Termination Cause 


Oc 


Described in 32.299 [50] 


Requested Action 


Oc 


Described in 32.299 [50] 


IVIultiple Operation 


Om 


Described in 32.299 [50] 


IVIultiple Unit Operation 


Oc 


Described in 32.299 [50] 


Subscriber Equipment 
Number 


Oc 


Described in 32.299 [50] 


Proxy Information 


Oc 


Described in 32.299 [50] 


Route Information 


Oc 


Described in 32.299 [50] 


Service Information 


Om 


This field holts additional 3GPP service specific parameter: 

- IIVIS Information, 

- PS Information 


Extended Information 


Oc 


This field holds the network/manufacturer specific extensions. 
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6.2.1.2 



Debit and Reserve Units Response Message 



Table 6.2.1.2 illustrates the basic structure of a Debit and Reserve Units Response message as used for IMS charging. 
This message is always used by the OCS as specified below, independent of the receiving IMS node and the operation 
type that is being replied to. 

Table 6.2.1.2: Debit and Reserve Units Response lUlessage Contents for lUIRFC, AS and IIUIS-GWF 



Field 


Category 


Description 


Session Identifier 


M 


Described in 32.299 [50] 


Operation Result 


M 


Described in 32.299 [50] 


Originator Host 


M 


Described in 32.299 [50] 


Originator Domain 


M 


Described in 32.299 [50] 


Operation Identifier 


M 


Described in 32.299 [50] 


Operation Type 


M 


Described in 32.299 [50] 


Operation Number 


M 


Described in 32.299 [50] 


Operation Failover 


Oc 


Described in 32.299 [50] 


Multiple Unit Operation 


Oc 


Described in 32.299 [50] 


Operation Failure 
Action 


Oc 


Described in 32.299 [50]. This field defines the operation if a failure has occurred at 
theOCSforSCURandECUR. 


Operation Event Failure 
Action 


Oc 


Described in 32.299 [50]. This field defines the operation if a failure has occurred at 
the OCS for lEC. 


Redirection Host 


Oc 


Described in 32.299 [50] 


Redirection Host Usage 


Oc 


Described in 32.299 [50] 


Redirection Cache Time 


Oc 


Described in 32.299 [50] 


Proxy Information 


Oc 


Described in 32.299 [50] 


Route Information 


Oc 


Described in 32.299 [50] 


Failed parameter 


Oc 


Described in 32.299 [50] 


Service Information 


Oc 


This field holts additional 3GPP service specific parameter: 

- IMS Information, 

- PS Information 


Extended Information 


Oc 


This field holds the network/manufacturer specific extensions. 
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6.3 IMS Charging Specific Parameters 



6.3.1 Definition of IIVIS cinarging information 

The IMS Information parameter used for IMS charging is provided in the Service Information parameter. 

6.3.1 .1 IMS charging information assignment for Service Information 

The components in the Service Information that are use for IMS charging can be found in Table 6.3.1.1. 
Table 6.3.1.1 : Service Information used for IMS Charging 



Field 


Category 


Description 


Provided 

by IMS 

NE 


Service 
Information 


Om 


This is a structured field and holds the 3GPP specific parameter as defined in 
TS 32.299 [50]. For IMS Charging the IMS Information is used. 


All 


Subscription- 
Id 


Om 


Described in TS 32.299 [50] and contains the Private User Identity and / or Public 
User Identity/Identities 


All 


IMS 
Information 


Om 


This is a structured field and holds the IMS specific parameters. The details are 
defined in clause 6.3.1.2. 


All 


PS 

Information 


Oc 


This is a structured field and holds PS specific parameters. The complete structure 
is defined in TS 32.251 [11]. 


Not in 
l-CSCF 


GGSN Address 


Oc 


This field holds the IP-address of the GGSN that generated the GPRS Charging 
ID, as described in [1]. 


Not in 

l-CSCF, 

MGCF, 

BGCF 



6.3.1.2 



Definition of the IMS Information 



IMS specific charging information is provided within the IMS Information. The fields of the IMS Information which 
are different coved in several IMS network nodes are indicated by the node specific type. 

The detailed structure of the IMS Information can be found in table 6.3.1.2. 

Table 6.3.1.2: Structure of the IMS Information 



Field 


Category 


Description 


Provided 
by IIVIS NE 


Event Type 


Oc 


This field holds the SIP Method, the content of the SIP 'Event' 
header and the content of the SIP 'expires' header when present in 
the SIP request. 


All 


Node Functionality 


M 


This field contains the function of the node. 


All 


Role of Node 


Om 


This field specifies the role of the AS/CSCF. 


All 


User Session ID 


Om 


This field holds the session identifier. For a SIP session the 
Sess/on-/D contains the SIP Call ID. 


All 


Calling Party Address 


Om 


This field holds the address (SIP URI or TEL URI)URI of the party 
(Public User Identity or Public Service Identity) initiating a session 
or requesting a service. 


All 


Called Party Address 


Om 


For SIP transactions, except for registration, this field holds the 
address of the party (Public User ID or Public Service ID) to whom 
the SIP transaction is posted. 

For registration transactions, this field holds the Public User ID 
under registration. 


All 


Alternate Charged 
Party Address 


Oc 


The address of an alternate party that is identified by the AS at 
session initiation, and is charged in place of the calling party. 


AS only 
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Field 


Category 


Description 


Provided 
byllVISNE 


Requested Party 
Address 


Oc 


For SIP transactions this field holds the address of the party 

(Public User ID or Public Service ID) to whom the SIP transaction 

was originally posted. 

This field is only present if different from the Called Party Address 

parameter. 


S-CSCF and 
AS/MRFC 


Called Asserted 
Identity 


Oc 


The address of the final asserted identity. Present if the final 
asserted identity is available in the SIP 2xx response. 


S-CSCF and 
AS/MRFC 


Associated URI 


Oc 


This field holds a non-barred public user identity (SIP URI or TEL 
URI) associated to the public user identity under registration. 


S-CSCF, P- 
CSCF, 
l-CSCF 


Time Stamps 


Om 


This field holds the time of the SIP REQUEST and the time of the 
response to the SIP REQUEST. 


All 


Application Server 
Information 


Oc 


This field holds the SIP URI(s) of the AS(s) addressed during the 
session and the called party number (SIP URI, E.164), if an 
application server determines it. 


S-CSCF and 
MRFC 


Inter Operator Identifier 


Oc 


This field holds the identification of the network neighbours 
(originating and terminating) as exchanged via SIP signalling if 
available. 


All 


IMS Charging Identifier 


Om 


This field holds the IMS Charging Identifier (ICID) as generated by 
a IMS node for a SIP session. 


All 


Early Media 
Description 


Oc 


This field holds session and media parameters related to media 
components set to active during the SIP session establishment 
and before a final successful or unsuccessful SIP answer to the 
initial SIP INVITE request is received. Once a media component is 
set to active, subsequent status changes shall be registered. Since 
several SDP negotiations may occur during the SIP session 
establishment, this field may occur several times. 


Not in l-CSCF 


SDP Session 
Description 


Oc 


This field holds the content of an "attribute-line" (i=, c=, b=, k=, a=, 
etc.) related to a session. 


Not in 
l-CSCF 


SDP Media 
Component 


Oc 


This is a grouped field comprising several sub-fields associated 
with one media component. Since several media components may 
exist for a session in parallel these sub-fields may occur several 
times. 


Not in 
l-CSCF 


Served Party IP 
Address 


Oc 


This field holds the IP address of either the calling or called party, 
depending on whether the P-CSCF is in touch with the calling or 
the called party. 


P-CSCF 


Server Capabilities 


Oc 


This field contains the server capabilities as described in 3GPP TS 
29.229 [205]. 


l-CSCF 


Trunk Group ID 


Oc 


This field identifies the incoming and outgoing PSTN legs. 


MGCF 


Bearer Service 


Oc 


This field holds the used bearer service for the PSTN leg. 


MGCF 


Service Id 


Oc 


This field identifies the service the MRFC is hosting. For 
conferences the conference ID is used as the value of this 
parameter. 


MRFC 


Service Specific Info 


Oc 


This field contains service specific data if and as provided by an 
Application Server. 


AS 


Message Bodies 


Oc 


This field holds information about the Message body, Content- 
Type, Content-Length, Content-Disposition and Originator if 
available. 


P-CSCF, S- 

CSCF, MGCF 

and AS 


Access Network 
Information 


Oc 


This field contains the content of the P-header P-Access-Network- 
Info. 


All 


IMS Communication 
Service ID 


Oc 


This field contains the IMS communication service identifier if 
received in the P-Asserted-Service header in the SIP request. 


S-CSCF and 
AS 


Cause Code 


Oc 


This field contains the cause value. 


All 
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6.3.2 Detailed Message Format for offline charging 

The following chapter specifies per Operation Type the charging data that are sent by each of the IMS network elements 
for: 

• IMS session and IMS event (S/I/S/E) 

• S-CSCF, P-CSCF, MGFC, AS, IBCF 

• IMS session only (S/I/S) 

• MRFC 

• IMS event only (E) 

• I-CSCF, BGCF 



The Operation Types are listed in the following order: S (start)/I (interim)/S (stop)/E (event). Therefore, when all 
Operation Types are possible it is marked as SISE. If only some Operation Types are allowed for a node, only the 
appropriate letters are used (i.e. SIS or E) as indicated in the table heading. The omission of an Operation Type for a 
particular field is marked with "-" (i.e. SI-E). Also, when an entire field is not allowed in a node the entire cell is 
marked as "-". 
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Table 6.3.2.1 illustrates the basic structure of the supported fields in the Charging Data Request message for IMS 
offline charging. 

Table 6.3.2.1 : Supported fields in Charging Data Request Message 



Field 


Node Type 


S-CSCF 


P-CSCF 


I-CSCF 


MRFC 


MGCF 


BGCF 


AS 


Supported Operation Types 


S/l/S/E 


S/l/S/E 


E 


S/l/S 


S/l/S/E 


S/l/S/E 


S/l/S/E 




Session Identifier 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


Originator Node 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


Originator Domain 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


Destination Domain 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


Operation Type 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


Operation Number 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


Operation Identifier 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


User Name 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


Operation Interval 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


Origination State 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


Origination Timestamp 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


Proxy Information 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


Route Information 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


Operation Token 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


Subscriber Identifier 


SISE 


SISE 


- 


SIS 


- 


- 


SISE 


Service Information with PS and IMS Information 


Event Type 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


Role of Node 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


Node Functionality 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


User Session Id 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


Calling Party Address 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


Called Party Address 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


Alternate Charged Party Address 


- 


- 


- 


- 


- 


- 


S- 


Requested Party Address 


S--E 


- 


- 


S-- 


- 


- 


S--E 


Called Asserted Identity 


S--E 


- 


- 


S-- 


- 


- 


S--E 


Associated URI 


— E 


— E 


E 


- 


- 


- 


- 


Time stamps (see note 3) 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


Application server Information (see note 1) 


SISE 


- 


- 


SIS 


- 


- 


- 


Inter Operator Identifiers 
(see note 1 ) 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


IMS Charging Identifier 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


Early IVIedia Description 


S--E 


S--E 


- 


S-- 


S--E 


E 


S--E 


SDP Session Description 


SI-- 


SI-- 


- 


SI-- 


SI-- 


- 


SI-- 


SDP Media Component 


SI-- 


SI-- 




SI-- 


SI-- 


- 


SI-- 


GGSN Address 


SI-- 


SI-- 




SI-- 


SI-- 


- 


SI-- 


Served Party (see note 1) 


- 


SISE 


- 


- 


- 


- 


- 


Authorized OoS (see note 1) 


- 


SI-- 


- 


- 


- 


- 


- 


Server Capabilities (see note 1 ) 


- 


- 


E 


- 


- 


- 


- 


Trunk Group ID (see note 1) 


- 


- 


- 


- 


SISE 


- 


- 


Bearer Service (see note 1 ) 


- 


- 


- 


- 


SISE 


- 


- 


Service Id (see note 1) 


- 


- 


- 


SIS 


- 


- 


- 


Service Specific Info (see note 1) 


- 


- 


- 


- 


- 


- 


SISE 


Message Bodies (see note 2) 


SISE 


SISE 






SISE 




SISE 


Cause Code 


--SE 


--SE 


E 


--S 


--SE 


E 


--SE 


Access Network Information 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


IMS Communication Service ID 


S--E 


- 


- 


- 


- 


- 


S--E 


NOTE 1 : Only present if available in the CTF of the IMS node. 

NOTE 2: Present only if Messages Bodies is included in the SIP message that triggered the Charging Data Request. 

NOTE 3: Only present if ACR is triggered on a SIP message (e.g. SIP INVITE, SIP UPDATE). 
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Table 6.3.2.2 illustrates the basic structure of the supported fields in the Charging Data Response message for IMS 
offline charging. 

Table 6.3.2.2 : Supported fields in Charging Data Response Message 



Field 


Node Type 


S-CSCF 


P-CSCF 


l-CSCF 


MRFC 


MGCF 


BGCF 


AS 


Supported Operation Types 


S/l/S/E 


S/l/S/E 


E 


S/l/S 


S/l/S/E 


E 


S/l/S/E 




Session Identifier 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


Originator Node 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


Originator Domain 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


Destination Domain 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


Operation Type 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


Operation Number 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


Operation Identifier 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


User Name 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


Operation Interval 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


Origination State 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


Origination Timestamp 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


Proxy Information 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


Route Information 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 



6.3.3 Detailed Message Format for online charging 

The following table specifies per Operation type the charging data that are sent by each of the IMS network elements 
for: 

• IMS session and IMS event (I/U/T/E) 

• IMS-GWF, AS 

• IMS session only (I/U/T) 

• MRFC 



The Operation types are listed in the following order: I (initial)/U (update)/T (terminate)/E (event). Therefore, when all 
Operation types are possible it is marked as lUTE. If only some Operation types are allowed for a node, only the 
appropriate letters are used (i.e. lUT or E) as indicated in the table heading. The omission of an Operation type for a 
particular field is marked with "-" (i.e. lU-E). Also, when an entire filed is not allowed in a node the entire cell is 
marked as "-". 

Note that not for all structured fields the individual field members are listed in the table. Detailed descriptions of the 
fields are provided in TS 32.299 [50]. 
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Table 6.3.3.1 illustrates the basic structure of the supported fields in the Debit and Reserve Units Request for IMS 
online charging. 

Table 6.3.3.1 : Supported fields in Debit and Reserve Units Request Message 



Field 


Node Type 


IMS-GWF 


MRFC 


AS 


Supported 
Operation Types 


l/U/T/E 


l/U/T 


l/U/T/E 


Session Identifier 


lUTE 


lUT 


lUTE 


Originator Host 


lUTE 


lUT 


lUTE 


Originator Domain 


lUTE 


lUT 


lUTE 


Destination Domain 


lUTE 


lUT 


lUTE 


Operation Identifier 


lUTE 


lUT 


lUTE 


Operation Token 


lUTE 


lUT 


lUTE 


Operation Type 


lUTE 


lUT 


lUTE 


Operation Number 


lUTE 


lUT 


lUTE 


Destination Host 


lUTE 


lUT 


lUTE 


User Name 


lUTE 


lUT 


lUTE 


Origination State 


lUTE 


lUT 


lUTE 


Origination Timestamp 


lUTE 


lUT 


lUTE 


Subscriber Identifier 


lUTE 


lUT 


lUTE 


Termination Cause 


— T- 


— T 


— T- 


Requested Action 


lUTE 


lUT 


lUTE 


IVIultiple Operation 


lU-E 


lU- 


lU-E 


IVIultiple Unit Operation 


lU-E 


lU- 


lU-E 


Service Units Requested 


lU-E 


lU- 


lU-E 


Action Requested 


— E 


... 


— E 


Service Units Used 


-UT- 


-UT 


-UT- 


Subscriber Equipment Number 


lUTE 


lUT 


lUTE 


Proxy Information 


lUTE 


lUT 


lUTE 


Route Information 


lUTE 


lUT 


lUTE 


Extended Information 


lUTE 


lUT 


lUTE 


Service Information with PS and IIVIS Information _, 


Event Type 


lUTE 


lUT 


lUTE 


Role Of Node 


lUTE 


lUT 


lUTE 


Node Functionality 


lUTE 


lUT 


lUTE 


User Session Id 


lUTE 


lUT 


lUTE 


Calling Party Address 


lUTE 


lUT 


lUTE 


Called Party Address 


lUTE 


lUT 


lUTE 


Requested Party Address 


I--E 


I--E 


I--E 


Called Asserted Identity 


-UTE 


-UT 


-UTE 


Associated URI 


--TE 


- 


- 


Application Server Information 


lUTE 


lUT 


- 


Inter Operator Identifier 


lUTE 


lUT 


lUTE 


IIVIS Charging Identifier 


lUTE 


lUTE 


lUTE 


SDP Session Description 


IU-- 


lU- 


lU- 


SDP IVIedia Component 


IU-- 


lU- 


lU- 


GGSN Address 


IU-- 


lU- 


lU- 


Served Party 


- 


- 


- 


Server Capabilities 


- 


- 


- 


Trunk Group ID 


- 


- 


- 


Bearer Service 


- 


- 


- 


Service Id 


- 


lUT 


- 


Service Specific Info 


- 


- 


- 


Messages Bodies 


lUTE 


- 


lUTE 


Cause Code 


--TE 


--T 


-TE 


Access Network Information 


lUTE 


lUT 


lUTE 


IMS Communication Service ID 


1--E 


- 


l-E 
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Table 6.3.3.2 illustrates the basic structure of the supported fields in the Debit and Reserve Units Response for IMS 
online charging. 

Table 6.3.3.2: Supported fields in Debit and Reserve Units Response Message 



Field 


Node Type 


IMS-GWF 


MRFC 


AS 


Supported 
Operation Types 


l/U/T/E 


l/U/T 


l/U/T/E 


Session Identifier 


lUTE 


lUT 


lUTE 


Operation Result 


lUTE 


lUT 


lUTE 


Originator Host 


lUTE 


lUT 


lUTE 


Originator Domain 


lUTE 


lUT 


lUTE 


Operation Identifier 


lUTE 


lUT 


lUTE 


Operation Type 


lUTE 


lUT 


lUTE 


Operation Number 


lUTE 


lUT 


lUTE 


Operation Failover 


lUTE 


lUT 


lUTE 


Multiple Unit Operation 


lUTE 


lUT 


lUTE 


Operation Failure Action 


- 


- 


- 


Redirection Host 


- 


- 




Redirection Host Usage 


- 


- 


- 


Redirection Cache Time 


- 


- 


- 


Proxy Information 


- 


- 




Route Information 


- 


- 


- 


Failed parameter 


- 


- 


- 


Extended Information 


lUTE 


lUT 


lUTE 



6.3.4 Formal IMS charging parameter description 

6.3.4.1 IMS charging information for CDRs 

The detailed definitions, abstract syntax and encoding of the IMS CDR parameters are specified in TS 32.298 [51]. 

6.3.4.2 IMS charging information for charging events 

The detailed charging event parameter definitions are specified in 3GPP TS 32.299 [50]. 



£75/ 



3GPP TS 32.260 version 7.7.0 Release 7 80 ETSI TS 1 32 260 V7.7.0 (201 0-04) 



Annex A (informative): 
Bibliography 

a) The 3GPP charging specifications 



3GPP TS 32.252: "Telecommunication management; Charging management; Wireless Local Area 
Network (WLAN) charging". 

3GPP TS 32.270: "Telecommunication management; Charging management; Multimedia 
Messaging Service (MMS) charging". 

3GPP TS 32.271: "Telecommunication management; Charging management; Location Services 
(LCS) charging". 

3GPP TS 32.296: "Telecommunication management; Charging management; Online Charging 
System (OCS) applications and interfaces". 

b) Common 3GPP specifications 

3GPP TS 22.101: "Service aspects; Service Principles". 

3GPP TS 22.1 15 "Service aspects; Charging and Billing". 

3GPP TS 23.003: "Numbering, addressing and identification". 

3GPP TS 27.001 : "General on Terminal Adaptation Functions (TAF) for Mobile Stations (MS)". 

c) other Domain and Service specific 3GPP / ETSI specifications 

d) Relevant ITU Recommendations 

ITU-T Recommendation D.93: "Charging and accounting in the international land mobile 
telephone service (provided via cellular radio systems)". 

ITU-T Recommendation E.164: "The international public telecommunication numbering plan". 

ITU-T Recommendation Q.767: "Application of the ISDN user part of CCITT signalling System 
No.7 for international ISDN interconnections". 

ITU-T Recommendation X.25: "Interface between Data Terminal Equipment (DTE) and Data 
Circuit-terminating Equipment (DCE) for terminals operating in the packet mode and connected to 
public data networks by dedicated circuit". 

ITU-T Recommendation X. 121: "International numbering plan for public data networks". 

e) Relevant IETF RFCs 

IETF RFC 959 (1985): "File Transfer Protocol". 



£75/ 



3GPP TS 32.260 version 7.7.0 Release 7 



81 



ETSI TS 132 260 V7.7.0 (2010-04) 



Annex B (informative): 

Message Flows for Service Termination by OCS 

This annex describes several scenarios related to IMS service termination in IMS-GWF. 

SIP messages and Diameter transactions associated with these charging scenarios are shown primarily to illustrate the 
service termination procedures. They are not intended to be exhaustive and depend on the Diameter Credit Control 
Requests triggers configured by the operator. The triggers for sending Debit and Reserve Unit Requests from the IMS- 
GWF to the OCS are defined according to table 5.3.1. 



B.1 Scenario 1 - Session Related (SCUR): Service 
Termination on reception of an initial SIP INVITE 
Request 



UE 



P-CSCF 



S-CSCF 



IMS-GWF 



OCS 



1. SIP Request (INVITE) 



4. 4xx,5xx,6xx (Error-Info) 



4. ACK 



1. SIP Request (INVITE) 



4. 4xx,5xx,6xx (Error-Info) 



4. ACK 



1. SIP Request ( INVITE) 



Service 
Control 



4. 4xx,5xx,6xx (Error-Info) 



4. ACK 



2. Debit and Reserve Units 
Request (INITIAL) 



3. Debit and Reserve Units 

Response (Service 
Termination) 



Figure B.1.1 : Service Termination triggered by an initial SIP Request 
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B.2 Scenario 2 - Session Related (SCUR): Service 
Termination triggered after an early SIP Dialog is 
established 



UE 



P-CSCF 



S-CSCF 



IMS- 
GWF 



OCS 



SIP early dialog established (Initial Request: SIP INVITE) 



5. 4xx,5xx,6xx (Error-Info) to 
the INVITE request 



5. SIPACK 



1.200OK 



1. 200 OK 



Service 
Control 



4. SIP BYE (Reason) 



2. Debit and Reserve Units 

Request (UPDATE) 

» 

3. Debit and Reserve Units 
i^esponse (Service Termination) 



4. SIP BYE (Reason) 



4. 200 OK to the SIP BYE 



5. 4xx,5xx,6xx (Error-Info) to 
the INVITE request 



4. 200 OK to the SIP BYE 



5. 4xx,5xx,6xx (Error-Info) to 
the INVITE request 



5. SIPACK 



5. SIPACK 



The SIP Session is not established 



Figure B.2.1 : Service Termination triggered by the 200OK response to the initial INVITE 
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UE 



P-CSCF 



S-CSCF 



IMS-GWF 



OCS 



Early SIP dialog already established (SIP INVITE Initial method) 



1. SIP UPDATE 



1. SIP UPDATE 



5. 4xx, 5xx, 6xx (Error-Info) to 
_^ reject SIP UPDATE method 



5. 4xx, 5xx, 6xx (Error-Info) to 
reject SIP UPDATE method 



6. 4xx, 5xx, 6xx (Error-Info) to 
close Early Dialog 



6. 4xx, 5xx, 6xx (Error-Info) 
to close Early Dialog 



6. ACK 



6. ACK 



1. SIP UPDATE 



Service 
Control 



4. SIP CANCEL to the INVITE 
_^ transaction (Reason) 



5. 4xx, 5xx, 6xx (Error-Info) to 
. reject SIP UPDATE method 



6. 4xx, 5xx, 6xx (Error-Info) 
_, to close Early Dialog 



6. ACK 



4. 200 OK to CANCEL In 
step 4 



2. Debit and Reserve Units 
Request (UPDATE) 



3. Debit and Reserve Units 
Response (Service Termination) 



4. SIP CANCEL to the INVITE 
transaction (Reason) 



4. 200 OK to CANCEL In 
step 4 



The SIP Session Is not established 



Figure B.2.2 : Service Termination triggered by an UPDATE request within an early SIP dialog 
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UE 



P-CSCF 



S-CSCF 



IMS-GWF 



ocs 



Early SIP Dialog Is already established (Initiated with a SIP INVITE) 



1. SIP UPDATE 



3. 4xx, 5xx, 6xx (Error-Info) to 
reject SIP UPDATE method 



7.4xx,5xx, 6xx (Error-Info) to 
_^ release the 'early' dialog 



7. ACK 



1. SIP UPDATE 



3. 4xx, 5xx, 6xx (Error-Info) to 
reject SIP UPDATE method 



7.4xx,5xx, 6xx (Error-Info) to 
release the 'early' dialog 



7. ACK 



1. SIP UPDATE 



1. SIP UPDATE 



1. SIP UPDATE 



2. 200OK 



2. 200OK 



Service 
Control 



5. SIP CANCEL (Reason) to 
release the SIP early dialog 



6. 4xx, 5xx, 6xx (Error-Info) to 
^ reject SIP UPDATE method 



7.4xx,5xx, 6xx (Error-Info) to 
release the 'early' dialog 



7. ACK 



5. 200OKtoSIPCANCEL 



3. Debit and Reserve Units 
Request (UPDATE) 



4. Debit and Reserve Units 
_gesponse (Service Termination) 



5. SIP CANCEL (Reason) to 
release the SIP early dialog 



5. 200OK to SIP CANCEL 



The SIP Session Is not established 



Figure B.2.3 : Service Termination triggered by the 200OK to an UPDATE request within an early SIP 

dialog 
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B.3 Scenario 3 - Session Related (SCUR): Service 

Termination triggered after a confirmed SIP Dialog is 
established 



UE 



P-CSCF 



S-CSCF 



IMS-GWF 



OCS 



Confirmed SIP dialog already established 



LSIPre-INVITE 



5. 4xx, 5xx, 6xx (Error-Info) 
to reject the SIP re-INVITE 



5. ACK 



6. SIP BYE to release the 
Dialog (Reason) 



6. 200 OK 



1. SIP re-INVITE 



5. 4xx, 5xx, 6xx (Error-Info) 
, to reject the SIP re-INVITE 



5. ACK 



6. SIP BYE to release the 
Dialog (Reason) 



6. 200 OK 



1. SIP re-INVITE 



Service 
Control 



2. Debit and Reserve Units 
Request (UPDATE) 



4. SIP BYE to release the Dialog 
^ (Reason) 



3. Debit and Reserve Units 
Response (Service Termination) 



4. SIP BYE to release the Dialog 
(Reason) 



5. 4xx, 5xx, 6xx (Error-Info) 
, to rejectthe SIP re-INVITE 



5. ACK 



6. SIP BYE to release the 
Dialog (Reason) 



6. 200 OK 



4. 200 OK to SIP BYE 



4. 200 OK to SIP BYE 



The SIP Session is released 



Figure B.3.1 : Service Termination triggered by a re-INVITE request within a confirmed SIP dialog 
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UE 



P-CSCF 



S-CSCF 



IMS-GWF 



OCS 





The SIP Sessio 


n is already established 








\ 


1 . SIP re-INVITE 


1. SIP re-INVITE 


1. SIP re-INVITE 


1. SIP re-INVITE 


/ 


6.4xx, 5xx, 6xx (Error-Info) 
to reject the re-INVITE 


6.4xx, 5xx, 6xx (Error-Info) to 
^ reject the re-INVITE 


1. SIP re-INVITE 










2. 200OK 




2. 200OK 








'^ 










Service 
Control 










3. Debit and Reserve Units 
Request (UPDATE) 




5. SIP BYE (Reason) 


4. Debit and Reserve Units 
^sponse (Service Termination 




5. SIP BYE (Reason) 








6.4xx, 5xx, 6xx (Error-Info) 
^ to reject the re-INVITE 


5. 200OK 




6. ACK ^ 


6. ACK ^ 


6. ACK 




7. SIP BYE (Reason) 


7. SIP BYE (Reason) 


7.SIP BYE (Reason) 




7. 200OK ^ 


7. 200OK ^ 


7. 200OK 












5. 200OK 












^ 



The SIP Session is released 



Figure B.3.2: Service Termination triggered by the 200OK response to a re-INVITE request within a 

confirmed SIP dialog 
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UE 



P-CSCF 



S-CSCF 



IMS-GWF 



OCS 



1 . Confirmed SIP dialog already established 



2. Service Control 
(Reauth. Trigger, 
Quota Expired...) 



5. SIP BYE (Reason) 



5. SIP BYE (Reason) 



5. 200 OK 



6. SIP BYE (Reason) 



6. SIP BYE (Reason) 



6. SIP BYE (Reason) 



6. 200 OK 



6. 200 OK 



6. 200 OK 



3. Debit and Reserve Units 
Request (UPDATE) 



4. Debit and Reserve Units 

Response (Service 
< Term i nat i on) 



5. 200 OK 



The SIP Session is released 



Figure B.3.3 : Service Termination triggered by the Charging Application procedures as defined in 

TS 32.299 [50] within a confirmed SIP dialog 
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B.4 Scenario 4 - Session Unrelated (ECUR): Service 

Termination on reception of an initial SIP non-INVITE 
Request 



UE 



P-CSCF 



S-CSCF 



IMS-GWF 



OCS 



1. SIP Request (e.g. SUBSCRIBE) 1. SIP Request (e.g. SUBSCRIBE) 



4. 4xx, 5xx, 6xx (Error-Info) 



4. 4xx, 5xx, 6xx (Error-Info) 



1. SIP Request (e.g. SUBSCRIBE) 



Service 
Control 



2. Debit and Reserve Units 
Request (INITIAL) 



3. Debit and Reserve Units 
Response (Service Termination) 



4. 4xx, 5xx, 6xx (Error-Info) 



Figure B.4.1 : Service Termination triggered by the reception of a non-INVITE SIP request 
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B.5 Scenario 5 - Session Unrelated (lEC): Service 

Termination on reception of an initial SIP non-INVITE 
Request 



UE 



P-CSCF 



S-CSCF 



IMS-GWF 



OCS 



1. SIP Request (e.g. SUBSCRIBE) 



1. SIP Request (e.g. SUBSCRIBE) 



4. 4xx,5xx,6xx (Error-Info) 



4. 4xx,5xx,6xx (Error-Info) 



1. SIP Request (e.g. SUBSCRIBE) 



Service 
Control 



2. Debit Units Request (EVENT) 



3. Debit Units Response (Service 
Termination) 



4.4XX, 5xx, 6xx (Error-Info) 



Figure B.5.1 : Service Termination triggered by the reception of a non-INVITE SIP request 
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